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Abstract 

A  formal  specification  of  the  sixth  revision  of  the  Soar  architecture  in  the  Z 
notation  was  constructed  to  elucidate  and  clarify  the  definition  of  Soar  and  to 
guide  its  implementation.  Soar  is  a  cognitive  architecture  that  has  been  success¬ 
fully  applied  to  many  domains  and  has  been  proposed  as  an  exemplar  unified 
theory  of  cognition.  Z  is  a  model  theoretic  specification  language  based  in  set 
theory  that  has  syntax  and  type  checking  programs  available.  The  specification 
has  a  complete  coverage  of  the  architecture,  a  low  level  of  abstraction  and  a 
considerable  implementation  bias. 
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For  Allen  Newell  (1927-1992)  —  who  taught  me  that  com¬ 
puter  science  is  an  empirical  quantitative  discipline. 


— B.G.M. 
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Chapter  1 

Introduction 


1.1  An  Introduction  and  the  Intended  Audi¬ 
ence 

A  formal  specification  of  the  sixth  revision  of  the  Soar  cognitive  architecture 
[LNR87]  was  constructed  in  the  Z  specification  notation  [Spi89,  Spi88].  Soar 
is  a  cognitive  architecture  that  has  exhibited  a  wide  variety  of  performance  in 
domains  such  as:  machine  learning  fLRN84],  cognitive  modehng  jAkyOO,  DS90. 
JRS91].  development  [SK91j,  natural  language  processing  (LLN91],  expert  sys¬ 
tems  iHPS89'  and  robotics  [LYHT911. 

This  specification  was  written  to  guide  the  construction  of  implementations 
of  Soar  and  to  facilitate  the  understanding  and  extension  of  the  Soar  archi¬ 
tecture.  Formal  specification  has  simultaneously  been  applied  to  two  other 
related  computional  architectures  by  Iain  Craig  of  the  University  of  Warwick, 
OK  [Cra91j.  Craig  used  Z  to  specify  blackboard  architectures  and  his  Cas¬ 
sandra  architecture  and  similarly  applied  the  specification  to  guide  Casandra's 
implementation. 

The  Z  notations  is  introduced  as  it  is  used.  It  is  largely  founded  upon 
familiar  set  theory,  but  most  readers  will  be  better  served  by  first  reading  an 
introductory  text,  such  as  [PTS91,  Wor92,  Hay85],  and  the  Z  manual  [Spi89j. 

Artificial  intelhgence  researchers  who  have  an  interest  in  understanding  the 
details  of  Soar  will  find  many  answers  to  their  questions  here.  Indeed,  the  pro¬ 
cess  of  writing  the  specification  has  made  clear  many  details  of  the  architecture 
to  its  implementors  and  founders.  Considerable  knowledge  of  the  Soar  architec¬ 
ture  from  less  formal  sources,  such  as  [LCAS90],  would  ease  and  enhance  the 
reader’s  understanding.  Z  specifiers  will  most  likely  find  this  difficult  reading, 
but  we  do  draw  some  conclusions  about  the  strengths  and  weaknesses  of  using 
Z  for  a  large,  detailed,  low-level  specification  of  a  computational  architecture. 
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1.2  The  History  and  Philosophy  of  the  Speci¬ 
fication 

In  January  1990  we  began  an  effort  to  re-implemen:  the  current  Soar  archi¬ 
tecture,  intending  only  a  few  well  understood  modifications.  As  we  proceeded, 
it  quickly  became  clear  that  the  limiting  factor  was  our  understanding  of  the 
details  of  the  architecture  itself  Although  Soar's  architecture  description  pa¬ 
pers  ILNR87,  LRN86]  and  manual  ILCA5901  described  some  of  the  architecture, 
they  were  out  of  date  with  the  current  system  (Soar  5.2),  at  too  high  a  level  of 
abstraction  and  had  obvious  inconsistencies  with  the  system. 

In  an  earlier  revision  of  Soar  (4.2)  a  small  module  (preference  semantics)  had 
been  forr'.alized  in  first  order  logic  iLai86!.  When  we  updated  and  reorganized 
this  formalization,  we  discovered  that  it  had  a  pleasing  clarity  and  disambi- 
guity  that  allowed  us  to  quickly  answer  precise  questions  about  the  module’s 
operation. 

After  considerable  reflection,  we  decided  to  undertake  a  formal  specification 
of  the  basic  functionality  of  the  architecture.  Oui  hope  is  that  this  document 
will  become  the  definitional  standard  of  Soar.  That  is.  the  specification’s  terms 
will  become  the  language  that  we  use  to  discuss  the  architecture.  And.  when 
we  change  the  architecture,  we  will  first  update  the  specification  to  flush  out 
our  understanding  of  the  changes,  and  then  distribute  the  changed  specification 
for  comment.  This  way,  the  detailed  content  of  the  architecture  will  not  remain 
hidden  in  the  implementation  and  become  obscured  with  time. 

After  an  initial,  unsuccessful  attempt  to  formally  specify  the  architecture  in 
an  ad  hoc  language,  we  undertook  a  small  survey  of  the  popular  specification 
languages.  Our  intuition  was  that  a  model  theoretic  language  would  serve  the 
purpose  of  specifying  a  cognitive  architecture  better  than  an  algebraic  system 
such  as  Larch  [Gut90l.  We  looked  at  Z.  VDM  [Jon90.  JS90J,  and  OBJ  [GW88:, 
but  chose  Z.  Z  appealed  most  to  us  because  of  its  strengths  in  composing  small 
specifications  into  larger  specifications,  the  availabihty  of  good  programs  to 
textually  format,  syntax  and  type  check  its  specifications  and  the  local  expertise 
here  at  Carnegie  Mellon  with  Z  [Gar91,  DG891. 

Although  Z  has  proved  a  very  capable  specification  language  it  lacks  two 
properties  that  would  have  considerably  simplified  our  task.  First,  Z’s  lack  of  a 
full  execution  semantics  forced  us  to  use  a  cumbersome  state  machine  notation. 
Second,  although  we  agree  that  not  all  specifications  written  in  a  language 
should  be  executable,  if  Z  was  directly  interpretable  it  would  have  allowed  us 
to  much  more  quickly  debug  the  specification. 
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1.3  The  Specification’s  Coverage  and  Implemen 
tation  Bias 

The  specification  is  intended  to  cover  all  the  functionality  of  what  we  view  as 
“the  Soar  architecture”,  and  avoid  details  that  are  specific  to  the  implemen¬ 
tation.  Initially  we  felt  that  the  ideal  specification  would  be  a  very  abstract 
specification  of  the  architecture  with  little  implementation  bias  because  an  ab¬ 
stract  specification  would  simplify  the  modification  of  the  specification  and  help 
to  prevent  discourse  on  the  design  from  being  overwhelmed  in  details. 

Several  problems  quickly  derailed  our  aspirations  for  an  abstract  specifi¬ 
cation.  We  wanted  the  specification  to  guide  our  re-implementation  of  Soar. 
We  desired  an  easily  instrumented  and  flexibly  modified  implementation.  This 
drove  us  to  produce  a  more  detailed  specification  that  could  be  used  eis  an  index 
into  the  implementation.  Also,  as  we  have  never  had  any  specification  of  the 
architecture  that  was  more  concrete  than  general  prose  but  less  concrete  than 
code,  we  found  it  difficult  to  produce  abstract  specifications  that  had  sufficient 
detail  to  guide  the  implementation. 

The  result  is  a  specification  that  abstracts  away  from  many  implementation 
details  but  is  a  very  detailed  accounting  of  the  operation  of  the  system.  Some 
implementation  oriented  details,  such  as  techniques  for  inserting  “hooks”  into 
the  system,  Soar’s  use  of  numbers,  and  a  conjunctive  match  condition  ordering 
algorithm  have  been  included  in  appendixes.  We  leave  the  problem  of  how  to 
produce  a  more  abstract  specification  to  future  Soar  researchers  as  they  attempt 
to  understand,  modify  and  implement  new  revisions  of  the  architecture. 


1.4  An  Overview  of  the  Architecture 

Figure  1.1  diagrams  a  module  and  control  oriented  view'  of  Soar,  and  Figure  1.2 
diagrams  a  module  and  data  oriented  view.  Soar  is  composed  of  four  modules 
and  IS  enclosed  in  an  interface,  which  we  call  the  external  interface.  Figure  1.1 
represents  each  module  by  a  rectangle,  each  state  machine  control  by  a  circle  or 
oval,  and  the  calling  hierarchy  by  arrows.  Figure  1.2  represents  each  module  in 
a  rectangle,  each  state  machine  with  a  circle  or  oval,  each  memory  with  a  heavy 
hned  rectangle,  and  the  reading  and  writing  of  each  memory  with  arrows. 

The  External  Interface  Soar  is  designed  as  a  situated  autonomous  agent 
that  directly  interacts  with  the  external  world,  but  an  actual  implementation 
of  the  architecture  is  a  program  that  allows  a  user  to  run  Soar  as  if  it  is  an 
embedded  agent.  We  distinguish  Soar  the  program,  from  Soar  the  architecture, 
by  wrapping  Soar  in  the  external  interface.  This  interface  contains  the  user 
interface  that  allow  users  to  view,  control  and  modify  the  execution  of  Soar, 
The  architecture  provides  only  one  operation  to  the  external  interface,  StepTL. 
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Figure  1.2:  Module  aij«^  Data  Block  Diagram 


StepTL  moves  Soar  one  step  forward.  It  acts  much  like  a  clock  line  of  a  CPU 
that  an  engineer  externally  pulses. 

Soar’s  four  modules  are:  the  top  level,  recognition  memory  (RM)  including 
chunking,  input  output  (lO)  and  the  decision  procedure  (Decide). 

Recognition  Memory  Recognition  memory  is  Soar’s  memory  model;  it  con¬ 
tains  a  long  term  memory  in  the  form  of  production  rules  called  production 
memory,  or  SPM.  Its  short  term  memory  is  temporary  memory,  TM,  which  is 
split  into  two  parts  c^Llled  working  memory,  WM,  and  preference  memory,  PM. 
As  aU  of  the  modules  of  Soar  read  and  write  temporary  memory.  Figure  1.2  de¬ 
picts  it  as  global  to  the  entire  system.  The  preference  phase  is  a  loop  that  recalls 
information  from  long  term  memory  until  no  new  recollections  are  available. 

Chunking  Chunking  is  Soar’s  learning  mechanism.  It  observes  the  changes 
to  temporary  memory  and  preference  phtise’s  recollections  and  stores  them  in 
two  trace  memories  (TtM).  From  these  and  Decide’s  goal  stack,  it  learns  new 
memories  and  adds  them  to  production  memory.  The  external  interface  steps 
the  top  level,  which  calls  StepPS  to  step  recognition  memory’s  preference  phase, 
which  calls  StepChunking  to  step  the  chunking  module. 

10  The  10  module  allows  Soar  to  communicate  with  the  outside  world.  The 
top  level  steps  lO’s  input  and  output  cycles  with  StepInputCycJe  and  StepOut- 
putCyde.  The  input  cycle  reads  perceptions  from  input  channels,  and  adds 
them  to  temporary  memory.  The  output  cycle  finds  the  subsets  of  temporary 
memory  that  represent  motor  actions  and  ships  them  out  output  channels  to 
the  outside  world. 

10  requires  transducers  to  map  Soar’s  motor  commands  into  a  form  that 
simulated  or  real  motor  controllers  can  understand,  and  to  map  the  perceptions 
of  simulated  or  real  perceptual  devices  into  Soar’s  form.  These  transducers  are 
housed  in  the  external  interface,  and  are  also  viewed  as  being  part  of  SoarlO, 
but  not  part  of  the  architecture. 

Decide  The  decision  procedure  is  Soar’s  universal  subgoaling  mechanism.  It 
maintains  two  goal  memories,  GM  and  IM,  and  interprets  the  contents  of  pref¬ 
erence  memory  as  requests  to  change  the  contents  of  pieces  of  working  memory. 
Whenever  a  set  of  requested  changes  are  not  consistent,  or  do  not  provide  a 
unique  change  to  working  memory,  decide  generates  a  new  goal  to  represent 
the  problem.  The  decision  procedure  has  two  state  machines:  working  memory 
phase  (WMPhase)  and  quiescence  phase  (QPhase),  stepped  by  StepWMPhase 
and  StepQPhase.  The  working  memory  phase  and  the  quiescence  phase  both 
step  the  impasser  and  preference  semantics,  with  Steplmpasser  and  StepPrefei- 
encePhase. 
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1.5  An  Overview  of  the  Specification 

The  specification  is  organized  into  eight  chapters  and  is  supplemented  with  four 
appendixes  on  implementation  related  considerations. 

1.  Chapter  1,  Introduction  —  this  introduction  and  overview  of  the  specifi¬ 
cation. 

2.  Chapter  2,  Specifying  Soar’s  Control:  State  Machines  —  introduces  the 
state  machine  convention  for  specifying  the  high  level  control  of  Soar. 

3.  Chapter  3,  Base  Symbol  Structures  —  introduces  the  basic  symbol  types 
which  Soar  composes  into  more  complicated  symbol  structures. 

4.  Chapter  4,  Temporary  Memory  and  Production  Memory  —  defines  the 
temporary  memory  and  production  memory  data  structures  that  are  used 
throughout  the  specification. 

5.  Chapter  5,  Recognition  Memory  —  defines  the  operation  of  the  recognition 
memory,  including  Soar’s  learning  mechanism.  Chunking. 

6.  Chapter  6,  10  —  specifies  Soar’s  mechanism  for  communicating  with  the 
external  world. 

7.  Chapter  7,  Decide  —  define's  Soar’s  universal  subgoaling  mechanism. 

8.  Chapter  8,  Top  Level  —  specifies  the  top  level  control  loop  that  orches¬ 
trates  the  execution  of  Soar’s  modules. 

9.  Appendixes  — 

(a)  Appendix  A,  Numbers  —  specifies  how  to  augment  the  base  symbol 
structures  of  Soar  with  a  single  type  of  numeric  type. 

(b)  Appendix  B,  An  Implementation  Discipline  —  describes  techniques 
for  creating  an  implementation  that  is  very  close  to  the  specification. 

(c)  Appendix  C,  Finer  Grained  Hooks  —  describes  a  technique  that 
would  allow  an  implementation  to  observe  and  modify  the  imple¬ 
mentation  at  a  finer  granularity  than  would  otherwise  be  supported 
by  the  specification. 

(d)  Appendix  D,  The  Reorderer  —  specifies  a  greedy  heuristic  reordering 
algorithm  to  sort  the  conditions  of  individual  Soar  productions  into 
an  order  that  on  average  matches  faster. 

Chapters  2,  3  and  4  cover  introductory  structure  and  are  required  to  un¬ 
derstand  the  remaining  chapters.  Chapters  5,  6,  7  and  8  cover  the  details  of 
the  major  components  of  Soar,  and  may  be  read  in  any  order.  Although  the  Z 
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specification  language  requires  a  bottom-up  definitional  approach,  chapters  5. 
7  and  8  refer  forward  in  prose  and  backwards  in  Z  and  prose.  Two  readings 
of  these  chapters  is  probably  required  to  clearly  understand  their  complicated 
interactions. 
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Chapter  2 

Specifying  Soar’s  Control: 
State  Machines 


This  chapter  describes  how  the  structure  of  Z  and  the  desired  properties  of  the 
design  and  implementation  of  Soar  conspire  to  produce  many  constraints  on 
the  specification  of  Soar.  Section  2.1  discusses  the  alternative  representations  of 
control  in  Z  Section  2.2  describes  the  technique  adopted  to  handle  this  problem: 
state  machines. 


2.1  Specifying  Soar’s  Control 

Z's  technique  for  modeling  a  computational  system  is  caUed  a  “sequential  sys¬ 
tem  model”  ([Spi89]  130-141).  Unfortunately,  Z's  sequential  system  model  does 
not  provide  sufficiently  rich  execution  semantics.  As  Soar  is  a  computational 
model  of  cognition,  a  large  part  of  its  design  is  its  flow  of  control.  Although  a 
specification  that  abstracts  away  from  Soar's  detailed  control  could  prove  use¬ 
ful,  to  guide  our  implementation  effort,  we  would  prefer  that  our  specification 
carefully  specify  Soar’s  flow  of  control. 

We  have  investigated  three  alternative  techniques  for  specifying  Soar’s  con¬ 
trol  in  Z:  prose,  execution  sequences  and  state  machines. 

We  began  by  specifying  pieces  of  the  architecture’s  flow  of  control  in  prose. 
This  prose  described  how  individual  state  changes  were  combined  in  sequences 
and  loops.  However,  it  lacked  clarity,  coverage  and  precision. 

Next,  we  experimented  with  specifying  control  by  defining  execution  se¬ 
quences.  We  constructed  the  set  of  all  sequences  of  slates  of  Soar,  and  then 
constrained  them  :o  start  with  an  initial  state  and  only  follow  defined  state 
changes.  However,  as  Soar  contains  several  components  each  of  which  contains 
isolated  control,  this  quickly  became  cumbersome.  Finally,  we  settled  upon  a 
state  machine  control  paradigm. 
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The  state  machine  control  makes  explicit  the  legal  sequencing  of  operations 
in  the  Soar  model  by  using  state  diagrams,  a  Z  representation  of  the  states 
of  the  machine  and  a  Z  sequential  operation  for  each  transition  of  the  state 
machine.  The  individual  transitions  of  the  state  machine  are  composed  into  a 
single  operation  that  moves  the  machine  forward  one  of  the  possible  transitions 
with  each  application. 

In  this  chapter  we  construct  a  prototype  state  machine  format  that  allows 
state  machines  to: 

•  initialize 

•  take  one  step  of  a  possible  set  of  transitions 

•  step  an  embedded  sub-state  machine 

•  determine  when  a  state  machine  has  finished  executing  and 

•  reset 

The  individual  state  machines  that  control  parts  of  Soar  are  constructed 
following  the  form  of  this  prototype,  and  then  composed  into  a  single  machine 
that  drives  all  of  Soar.  The  resulting  implementation  of  the  architecture  is 
controlled  from  an  interface  that  we  caU  the  external  interface  This  interface 
drives  Soar  step  by  step,  much  like  an  engineer  externally  pulses  the  clock  of  a 
computer  processor. 


2.2  The  Prototype  State  Machine 

This  section  defines  the  state  machine  control  conventions  by  exhibiting  a  state 
machine  prototype.  The  prototype  state  machine  is  diagrammed  in  Figure  2.1. 
The  states  of  the  machine  are  diagrammed  with  ovals,  and  the  operations  that 
move  the  system  between  states  are  diagrammed  as  arrows. 

The  Names  of  the  States  The  names  of  the  states  of  the  machine  are 
represented  in  Z  using  the  free  type  StateCounter.  In  this  case,  StateCounter  is 
defined  to  be  a  type  that  is  a  set  of  five  distinct  variables  named:  SMInitialState, 
SMSlState.  SMS2State,  SMS3State,  and  SMFinishedState. 

StateCoanler  ::=  SMInitialSiate  '■  SMSlState  SMS2State  | 

S MS  Z  State  \  SMFinishedState 

Free  types  are  Z’s  method  for  constructing  disjoint  unions  ([Spi89i  81).  They 
are  similar  to  union  types  in  C  ((KR88J  147).  but  are  mathematically  motivated 
(  BW90)  258).  In  this  case,  the  free  type  definition  introduces  only  new  variables 
so  it  acts  more  like  a  C  enumeration  (IKR881  39). 
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SMS20P2 


SMStepSS 


Figure  2.1:  State  Machine  Prototype 


Z  defines  the  free  type  notation  by  expansion  into  an  equivalent  Z  basic  type 
definition  (fSpi89]  50)  with  a  set  of  new  variables  of  disjoint  values.  In  the  first 
part  of  this  expansion,  StateCounCer  is  introduced  as  a  basic  type;  e.g.,  a  set  of 
values  with  no  predetermined  structure. 

[State  Counter] 

An  axiomatic  description  is  then  used  to  introduce  the  five  new  variables. 
The  part  of  the  axiomatic  definition  above  the  bar  is  called  the  declaration  or 
signature.  The  part  below  the  bar  is  called  the  predicate.  The  declaration  intro¬ 
duces  the  five  new  variables,  typing  them  as  elements  of  the  set  StateCounter. 
The  scope  of  variables  defined  in  an  axiomatic  description  is  everything  after 
the  bar  in  the  rest  of  the  specification.  The  predicate  part  defines  predicates  on 
the  variables  introduced  by  the  declaration.  In  this  case,  the  built-in  Z  pred¬ 
icate  disjoint  is  applied  to  a  sequence  of  the  singleton  sets  of  the  variables  to 
constrain  the  values  to  which  they  are  bound  to  be  distinct. 

SMJmtialState.  SMSlState.  SMS2State,  SMSSState, 

SMFinishedState  :  StateCounter 

disjoint {{SM Initials tate},  {SMSlState},  {SMS2State},  {SMSZState}, 

I  {SMFinishedState}) 


The  Functions  of  the  States  The  five  different  states  each  perform  unique 
functions  in  the  prototype  state  machine. 

1.  SMFinishedState  —  when  the  machine  is  not  being  used,  it  rests  in  this 
state.  The  driver  for  this  machine  calls  an  initialize  action  to  move  it  into 
the  SMInitialState. 

2.  SMInitialState  —  this  is  the  state  from  which  the  machine  begins  compu¬ 
tation. 

3.  SMSlState  —  in  this  state  the  SMSl  operation  is  applied  to  the  state. 

4.  SMS2State  —  in  this  state  the  SMS20P1  or  SMS20P2  operations  are 
applied  to  the  state,  or  SMStartSS  is  applied,  moving  the  machine  to 
state  S3. 

5.  SMS3State  —  in  this  state  the  SMStepS3  operation  is  appbed  to  step  a 
sub-state  machine.  When  the  sub-state  machine  has  finished,  the  SMFin- 
ish  operation  ends  the  execution  of  the  state  machine. 

Z's  sequential  system  model  uses  schemas  to  specify  almost  all  of  the  parts 
of  a  computational  model.  A  schema  can  specify  a  data  structure,  like  a  record 
structure  in  a  programming  language.  A  schema  can  represent  the  environment 
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(or  state)  of  a  computational  model,  like  the  declaration  of  global  variables  in 
a  programming  language.  A  schema  can  specify  predicates  on  an  environment, 
like  a  boolean  function  in  a  program  or  a  program  invariant.  A  schema  can 
also  specify  an  operation  that  changes  the  environment,  like  a  procedure  in  a 
programming  language.  Perhaps  Z’s  greatest  strength  is  its  schema  calculus. 
The  calculus  provides  a  rich  and  unifo.m  way  to  combine  schemas  that  are 
playing  any  of  these  roles. 

The  Total  State  of  the  Machine  The  prototype  state  machine’s  compu¬ 
tational  state  is  represented  here  using  a  schema  named  StateSchema.  ([Spi89] 
51).  Like  an  axiomatic  declaration,  the  part  above  the  bar  is  a  declaration  and 
below  the  bar  is  a  predicate.  The  scope  of  variables  defined  in  a  schema  is  only 
the  text  from  the  bar  to  the  end  of  the  schema  box.  The  scope  of  the  name  of 
the  schema  is  tdl  the  specification  past  the  bottom  bar  of  the  schema  definition. 
The  prototype’s  state  schema  defines  only  state_counter  to  remember  the  state 
the  machine  currently  occupies.  In  the  specification  of  an  actual  Soar  state 
machine,  the  declaration’s  ellipses  (...)  would  declare  other  variables  to  enrich 
the  state  model,  and  the  predicate’s  ellipses  would  define  state  invariants, 

, _ StaieSchema _ 

i  state-counter  ;  StateCounter 


Initial  States  fc_  the  Machine  The  Z  convention  to  define  a  predicate  on 
the  initial  states  of  a  sequential  system  model  is  to  prefix  the  name  of  the  state 
schema  with  '‘inif”  ((Spi89i  131).  Thus  the  InitStaieSchema  defines  a  predicate 
which  initial  states  of  the  prototype  state  machine  must  satisfy.  The  declaration 
part  of  this  schema  references  the  schema  StateSchema.  Z  defines  this  reference 
to  mean  that  the  new  schema  contains  till  of  the  declarations  of  the  referenced 
schema  and  all  of  the  referenced  schemas’s  predicates  are  conjoined  with  the 
new  schema’s  predicate  ([Spi89]  53). 

_ InitState  Schema _ 

i  StateSchema 

state-Counter  =  SMFxnishedState 
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The  expanded  definition  of  InitStateSchema,  shown  below,  is  that  of  a 
schema  with  the  same  signature  as  the  state  schema,  but  the  state  counter 
is  constrained  to  start  in  the  finished  state.  Again,  the  ellipses  is  used  to  signify 
that  the  initial  state  schemeis  of  state  machines  might  contain  other  restrictions. 

I _ InitStateSchema _ 

I  state -Counter  :  StateCounter 


\  state-Counter  —  SMFinishedState 


The  General  Form  of  Operations  After  defining  the  form  for  the  state  of 
our  sequentiaJ  system  model  and  constrained  its  initial  values,  we  must  define 
operations  that  move  the  system  through  its  state  space.  Operations  that  change 
the  state  of  the  sequential  system  are  called  sequential  operations  (!Spi89;  130). 
A  sequential  operation  is  a  relation  on  pairs  of  states.  Z  uses  relations  instead  of 
functions  to  allow  the  specification  of  non-deterministic  operations.  The  speci¬ 
fication  takes  good  advantage  of  this:  for  example,  decide  non-deterministically 
selects  between  indifferent  operator  candidates  by  using  an  non-deterministic 
sequential  operation  schema. 

For  a  schema  to  define  a  relation  between  two  states  it  must  have  a  way  to 
reference  the  component  variables  of  both  states.  Z’s  technique  is  to  construct 
a  schema  that  references  both  the  state  schema  and  a  copy  of  the  state  schema 
in  which  all  of  the  components  have  been  decorated  (post  appended)  with  an 
single  quote  (')  (!Spi89(  32).  The  undecorated  slate  variables  refer  to  the  start 
state  and  the  decorated  components  refer  to  the  resultant  state  For  example, 
the  SMOperation  schema  defines  all  of  the  components  of  StateSchema  and  a 
decorated  copy  of  the  components. 

. _ SMOperation _ 

state -Counter ,  state -counter'  :  StateCounter 
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Decorating  all  of  the  components  of  a  schema  is  common  enough  that  dec¬ 
orating  the  schema  name  is  defined  to  decorate  all  of  its  components.  For 
example,  SMOpeiation  could  be  defined  by  referencing  both  a  decorated  and 
an  undecorated  copy  of  the  state  schema. 

, _ SMOperation _ 

StateSchema 

StaieSchema' 


However,  sequential  operations  are  so  common  that  a  second  short  hand,  A. 
is  defined  to  mean  the  schema  and  a  decorated  copy  of  the  schema. 

. _ SMOperation _ 

AStateSchema 


The  Form  of  a  State  Transition  Now  that  we  have  defined  the  state  of 
the  system,  its  initial  states  and  the  general  form  of  a  state  changing  operation, 
we  need  to  define  the  form  of  typical  state  machine  operations.  When  a  state 
machine’s  caller  wants  to  initialize  the  system,  it  calls  an  initialization  operation. 
Operations  of  this  form  pairs  state  schemas  with  counters  in  the  finished  state 
to  state  schemais  with  counters  in  the  initial  state. 

_ S  Mlmtializt _ 

instate  Schema 

state  ^counter  —  SMFinishedState 
state  ^counter'  =  SMInitialState 
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Start  Transitions  When  a  state  machine  can  loop  in  a  state,  the  operation 
that  starts  the  loop  by  moving  to  the  state  is  named  with  “Start”. 


_ SMStartS  1 _ 

AStateSchema 

state— counter  —  SMInitialState 


state-counter'  —  SMS  \  State 


Simple  Transitions  The  SMSl  operation  provides  the  form  for  the  simplest 
type  of  operation.  It  performs  its  one  and  only  change  to  the  state,  represented 
by  ellipses.  At  the  same  step  it  moves  the  state  machine  into  the  next  state, 
SMS2. 

—  SMS  1 _ 

AStateSchema 

i  state-counter  =  SMSl  State 


'  state -counter'  =  SMS2State 
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Looping  and  Compound  Transitions  SMS2  style  operations  are  more 
complex  than  the  SMSl  style  operation.  At  each  step  the  machine  can  change 
the  sequential  system  state  by  either  the  SMS20P1  operation  or  the  SMS20P2 
operation.  After  the  application  of  these  operations,  the  machine  remains  in 
SMS2State  allowing  SMS2  to  loop  until  SMS20P1  and  SMS20P2  are  both  no 
longer  apphcable. 

_SM520P1 _ 

I  ^StateSchema 

state -Counter  =  SMS2State  =  state-counter' 


—  SMS2  OP2 _ 

AStateSchema 

state-COunter  —  SMS2Staie  =  state -counter' 


We  would  like  to  be  able  to  define  an  operation  that  allows  the  state  machine 
to  take  either  an  SMS20P1  or  an  SMS20P2  transition.  The  Z  schema  calculus 
(fSpi89l  74)  allows  the  convenient  combination  of  schemas  by  extending  the 
standard  logical  operations  of  and  (a),  or  (v)  and  not  (-'  )  to  apply  to  schemas. 
Two  schemas  may  be  combined  with  A  or  v  if  their  signatures  give  all  shared 
variables  the  same  types.  The  signature  of  the  resulting  schema  contains  all 
of  the  signature  elements  of  both  of  the  schemas  and  conjoins  or  disjuncts  the 
predicates  of  the  two  schemas.  Any  schema  may  be  negated:  the  resulting 
schema  has  the  same  signature  and  the  negation  of  the  predicate. 

SMS  2  =  5M520P1  v  SMS20P2 

The  SMS2  operation  is  defined  as  an  “or”  of  the  SMS20P1  transition  and 
the  SMS20P2  transitions.  The  =  operation  names  a  new  schema  to  be  the  vadue 
of  a  schema  calculus  expression.  This  new  transition  satisfies  the  conditions  of 
either  SMS20P1  or  SMS20P2.  The  SMS2  operation  schema  does  not  actually 
need  to  be  defined;  the  machine  works  identically  with  just  the  SMS20P1  and 
the  SMS20P2  transitions  installed.  (We  define  such  transitions  only  to  give 
the  users  of  Soar  an  easy  way  to  observe  related  operations:  such  as  all  the 
operations  that  leave  a  state,  see  Appendix  B.  )  The  state  diagrams  wUl  not 
have  an  item  representing  the  compound  transitions  because  they  are  difficult 
to  draw:  some  cases  only  require  one  arrow  with  two  different  names,  but  some 
would  require  a  graphic  merging  of  arrows. 

In  a  sequential  system  model  not  all  operations  are  apphcable  to  all  states. 
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The  schema  calculus  provides  an  operation,  called  pre-condition  (pre  )  to  cal¬ 
culate  if  an  operation  is  applicable  ([Spi89l  72).  The  pre-condition  operation 
maps  a  sequentijil  operation  to  a  predicate  that  checks  if  all  of  the  conditions 
on  the  initial  state  of  the  operation  are  satisfied.  Essentially,  it  tests  a  schema 
for  membership  in  the  domain  of  the  transition  relation. 

SMStmtSS  checks  that  SMS2  is  no  longer  applicable  by  using  the  pre¬ 
condition  of  SMS2.  When  SMS2  is  no  longer  appbcable,  SMStartSS  moves 
the  state  into  SMS3Sta.te.  This  exit  transition  makes  SMS2State  a  while-do 
looping  state;  it  applies  SMS2  until  it  is  no  longer  applicable  and  then  exits. 

_ _ SMStartSZ _ 

SSiateSchema 

state^counter  =  SMS  2  State 

-  pre  SMS  2 

i  InitializeSubStateMachine 

! 

state -counter'  =  SMSZ  State 


SubState  Machine  Transitions  Soar  is  too  complicated  to  specify  with  just 
one  state  machine.  We  need  to  compose  machines  such  that  one  state  machine 
can  step  another  state  machine.  SMS3  prototypes  a  state  that  is  implemented 
by  a  sub-state  machine,  named  SubStateMachine.  When  SMStartS3  applies, 
it  initializes  the  sub-state  machine  using  InitializeSubStateMachine.  SMStepSS 
loops  in  the  SMS3State  and  applies  the  StepSubStateMachine  to  step  the  sub¬ 
state  machine. 

I _ SMStepS  3 _ 

.IStateSchema 

state-counter  =  SMSZState  =  state -counter' 

StepSubStateMachine 


SMSZ  =  SMStartSZ  v  SMStepS Z 
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SMFinish  checks  that  the  sub-state  machine  is  finished  by  checking  the  pre¬ 
condition  of  StepSubStateMa.chine.  and  moves  the  state  machine  into  its  SMFin- 
ishedState. 

_ _ SMFinish _ 

j  AStateSchema 

j  state  ^counter  =  SMSiState 

I  -1  pre  StepSubStateMachine 

I 

I  ... 

!  state-counter'  =  SMFinishedState 


Stepping  a  Machine  The  caller  of  a  state  machine  requires  a  single  com¬ 
pound  operation  to  step  a  sub-machine.  SMStep  is  a  prototype  of  an  operation 
to  step  an  entire  machine  forward  one  step.  The  stepper  allows  the  machine  to 
move  through  one  step  of  any  operation  except  its  initialization. 

SMStep  =  SMSiartSl  V  5Af51  v  5MS2  v  SMSZ  v'  SMFinish 

The  SMReset  operation  resets  the  state  machine  to  the  finished  state.  It 
is  designed  to  be  called  when  the  state  machine’s  execution  is  interrupted,  and 
would  be  drawn  as  in  arrow  from  every  state  to  the  finished  state.  As  it  is 
also  cumbersome  to  draw  this,  it  will  not  be  shown  in  the  other  state  machine 
diagrams.  In  an  implementation,  SMReset  is  designed  to  take  actions  to  recover 
the  state  of  the  implementation  that  would  otherwise  be  lost  by  an  initialize 
operation, 

_ SMReset _ 

AStateSchema 

!  state -counter'  =  SMFinishedState 

i 


The  prototype  state  machine  provides  a  convention  for  representing  compli¬ 
cated  control,  a  single  step  at  a  time,  using  Z’s  weak  state  relation  sequential 
operation  semantics.  The  convention  provides  templates  for: 

•  initialization 

•  start  transitions 

•  simple  transitions 

•  looping  and  compound  transitions 
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•  substate  machine  transitions 

•  finishing  transitions  and 

•  machine  stepping  transitions. 

The  specification  defines  each  piece  of  Soar’s  control  flow  in  a  state  machine, 
and  composes  them  into  a  single  operation  that  moves  Soar  one  atomic  control 
step. 
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Chapter  3 


Base  Symbol  Structures 


This  chapter  defines  the  base  sets  of  symbols  that  Soar  uses  to  construct  its 
knowledge  representations.  Soar  uses  two  base  set  of  symbols:  E  and  the  Spe- 
ciaJSymbol  set.  E  is  a  set  of  base  general  symbols  for  knowledge  representation. 
Soar  composes  these  symbols  to  construct  all  of  its  knowledge  structures.  Spe- 
ci&lSymbols  are  the  reserved  words  of  Soar.  They  are  symbols  with  meanings 
specific  to  the  operation  of  Soar. 

[E,  SpecialSymbol] 

Soar  partitions  E  into  the  sets  of  variable  symbols,  identifier  symbols,  and 
constant  symbols.  The  three  subsets  of  E  are  typed  as  elements  of  P  E,  the  set 
of  all  subsets  of  E  ('Spi89l  27).  The  Z  partition  predicate  relates  a  sequence  of 
sets  to  a  set  if  and  only  if  the  sets  in  the  sequence  are  disjoint  and  their  union 
IS  equal  to  the  set  ('Spi89;  125). 

Variable.  Identifier,  Constant  :  P  E 
!  (  Variable,  Identifier,  Constant)  partition  E 

As  many  definitions  allow  either  variables  or  constants  in  their  domain  we 
define  VariabJeOrConstant  for  brevity. 

'  VanableOr Constant  ;  P  E 
!  VariableOrConstant  =  Variable  J  Constant 

Also  many  definitions  use  either  an  identifier  or  a  constant  in  their  domain. 
Soar  users  commonly  refer  to  these  as  Symbols. 

Symbol  :  P  E 
I - 

Symbol  =  Identifier  u  Constant 
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The  SpecialSymbok  are  partitioned  into  PreferenceSymbols  and  Relation- 
Symbols.  The  PreferenceSymbols  appear  in  the  preference  slot  of  preferences. 
The  RelationSymbok  appear  in  the  syntajc  of  relational  tests  inside  of  produc¬ 
tions.  Typographically,  we  use  single  quoted  variable  names  to  emphasize  that 
these  are  constants  of  Soar,  but  to  Z  they  are  just  Z  variables.  As  the  symbol 
'  =  is  Soar’s  name  for  both  the  equaUty  relation  and  the  indifferent  preference, 
to  we  distinguish  them  with  subscripts  of  “r”  for  relation  and  “p”  for  preference. 

j  PreferenceSymbol,  RelattonSymbol  :  P  SpecialSymbol 
I  '®', =p  ' ,  '  fc  '  :  SpecialSymbol 
\  '=p', SpecialSymbol 

!  i  PreferenceSymbol.  RelattonSymbol)  pattiuon  SpecialSymbol 
j  RelationSymbol  =  {' 

PreferenceSymbol  = 

The  decision  procedure’s  input  language  is  the  set  of  preferences.  Prefer¬ 
ences  describe  properties  of  the  structure  of  Soar’s  short  term  memory.  The 
preferences  may  describe  a  property  of  a  single  object  in  memory,  called  unary, 
or  may  describe  a  property  of  two  objects  in  memory,  called  binary.  The  sets 
UnaryPreferenceSymboI  and  Binary PiefetenceSymboI  partition  the  preference 
symbols  into  those  that  can  appear  in  unary  preferences  and  those  that  can  ap¬ 
pear  in  binary  preferences.  All  of  the  binary  preference  symbols  are  also  unary, 
but  some  of  the  unary  preferences  (such  as  '  — can  not  appear  in  binary  pref¬ 
erences. 


UnaryPreferenceSymboI.  BinaryPreferenceSymbol  :  P  PreferenceSymbol 
U  nary  PreferenceSymbol  = 

j  BinaryPreferenceSymbol  =  '4£',=:p'} 
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The  specification  of  the  Soar  architecture  references  17  constant  symbols. 
The  disjoint  predicate  ensures  that  the  variables  all  take  no  distinct  values  from 
the  set  of  constants.  No  specific  identifiers  or  variables  are  defined  because 
Soar  uses  these  as  placeholders  that  describe  the  structure  of  its  knowledge 
representations,  but  not  the  specific  content. 

{  •  NIL  *  T *  GOAL  '  PROBLEM-SPACE  ‘  STATE  ‘  OPERATOR 
{  '  IMPASSE  * , '  OBJECT ' ,  ‘  ITEM  ' , '  ATTRIBUTE  ' ,  ‘  CHOICES  ' , 
j  *  CONSTRAINT-FAILURE  *  CONFLICT ‘  TIE  *  NO-CHANGE 
I  '  NONE  ' , '  MULTIPLE  ' , '  QUIESCENCE  ' , '  TYPE  '  ;  Constant 

disjoint  /{•  NIL  ■},{'T '},  {*  GOAL  PROBLEM-SPACE  '}. 

:  {'STATE'},  {'OPERATOR'},  {'IMPASSE'}, 

{  {'  OBJECT '},{'  ITEM  '}.  {'  ATTRIBUTE  '}, 

!  {'  CHOICES  '},  {'CONSTRAINT-FAILURE  '},{'  CONFLICT '}, 

'  {'  TIE  '},  {'  NO-CHANGE '},  {'  NONE  '}, 

{'  MULTIPLE  '},{'  QUIESCENCE  '},{'  T  '}, 

{'TYPE'}') 


32 


Chapter  4 


Temporary  Memory  and 
Production  Memory 


This  chapter  specifies  the  elements  of  two  of  Soar’s  memories:  temporary  mem¬ 
ory  (TM)  and  production  memory  (PM).  Temporary  memory  holds  TMEs,  a 
disjoint  union  type  constructed  from  Pteferences  and  WMEs.  The  preferences 
are  edso  stored  in  preference  memory  (PM),  and  the  working  memory  elements 
in  working  memory  (WM).  Temporary  memory  is  the  union  of  preference  and 
working  memory.  Production  memory  holds  productions  that  match  against 
working  memory,  instantiate,  fire  and  retract  to  modify  preference  memory. 


4.1  Preferences 

Soar’s  preferences  are  the  input  language  of  the  decision  procedure.  Decide 
reads  preference  memory  to  determine  how  to  change  working  memory.  Soar 
has  two  types  of  preferences:  unary  and  binary. 

A  Unary  preference  describe  a  property  of  an  identifier,  attribute,  value 
triple.  The  most  common  property  is  that  a  value  is  acceptable  for  installation 
in  WM  for  an  identifier,  attribute  combination,  called  a  slot. 

_ Unary  Preference _ 

id  :  Identifier 
attribute,  value  :  Symbol 
preference  :  Unary PreferenceSymbol 


We  must  de-structure  the  data  elements  conteuned  in  top  level  memories  to 
specify  general  data  invariants  of  Soar,  such  as  the  set  of  all  identifiers  currently 
in  use  anywhere  within  Soar.  Components  mappings  are  used  to  de-structure 
an  element  of  some  type  into  the  set  of  its  basic  symbols. 
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The  Una.ryPiefeTencesComponents  mapping  extracts  the  identifier,  attribute 
and  value  symbols  from  a  unary  preference. 

U nary  P  ref erencea  Components  :  Unary  Preference  — >  P 
I  V  u  :  UnaryPreference  • 

!  UnaryPreferencesComponents(u)  =  {u. id,  ti. attribute,  u.  value} 

Binary  preferences  describe  a  property  of  two  values  for  a  slot  to  Decide.  A 
common  property  described  is  that  the  identifier,  attribute  and  value  triple  is 
a  better  choice  for  installation  in  working  memory  than  the  identifier,  attribute 
and  referent  triple. 

_ BtnaryPreference _ 

I  id  :  Identifier 
'  attribute,  value  :  Symbol 

preference  ;  BinaryPreferenceSymbol 
referent  :  Symbol 


The  BinaryPreferencesComponents  mapping  extracts  the  identifier,  attribute, 
value  and  referent  symbols  from  a  preference. 

BinaryPreferencesComponents  :  BinaryPreference  — *  P  E 

V  b  :  BtnaryPreference  • 

'  BinaryPreferencesComponents(b)  — 

\  {b-id,  b. attribute,  b. value,  b. referent} 

The  preference  free  type  constructs  the  disjoint  union  of  unary  preferences 
and  binary  preferences.  The  UnarvP  and  BinaryP  total  injections  (!Spi89  106) 
ate  used  to  construct  a  Preference  from  a  unary  or  binary  preference. 

Preference  UnaryP {(UnaryPreference))  BinaryP {\BinaryPreferenceY 
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Given  a  preference,  you  can  check  if  it  is  constructed  from  a  unary  prefer¬ 
ence  or  a  binary  preference  by  testing  it  for  membership  in  the  range  of  the 
injectors  p  G  ran  UnaryP  or  p  €  Binary P  ([Spi89]  9).  The  inverse  func¬ 
tions,  UnaryP~'  or  BinaryP''  can  then  be  used  to  unpack  a  preference  into  its 
unary  or  binary  preference  ([Spi89]  101).  PreferencesComponents  de-structures 
a  preference  using  this  technique. 

[  PreferencesComponents  :  Preference  — *  P  Symbol 

V  p  :  Preference  • 

((p  G  ran  UnaryP  => 

Preferences  Components  (p)  = 

UnaryP  reference  sComponents{  UnaryP~'  [p)))  A 
!  (p  G  ran  BinaryP  =5> 

P  reference  sComponents(p)  — 

BinaryPreferencesComponents  ( Binary  P''  ( p ) ) ) ) 

The  specification  frequently  creates  preferences,  so  two  functions  are  pro¬ 
vided  to  map  the  components  of  preferences  to  a  preference.  The  p,  operator 
acts  much  like  a  programming  language’s  let  construct  and  the  6  operator  in¬ 
stantiates  a  schema  using  the  values  for  its  components  provided  in  the  current 
scope  ([Spi89j  61,  64). 

make  Unary  Preference  : 

Identifier  x  Symbol  x  Symbol  x  UnaryPreferenceSymbol 
— •  Preference 

makeBtnaryPreference  : 

Identifier  x  Symbol  x  Symbol  x  BinaryPreferenceSymbol  x  Symbol 
— *  Preference 

V  i  :  Identifier-,  a,  v  :  Symbol',  p  :  UnaryPreferenceSymbol  • 
make  Unary  Prefer€nce{i,  a,  V .  p)  = 

UnaryP  ((p  Unary  Preference  \ 

id  =  i  A.  attribute  =  a  A  value  =  v  A  preference  =  p  • 

!  6  U naryPreference ) ) 

Vi-  Identifier:  a,  v.  r  :  Symbol;  p  :  BinaryPreferenceSymbol  • 
makeBinaryPreference{i.  a.  v,p,  r)  = 

BinaryP({p  BinaryPreference 

id  =  i  A  attribute  =  a  A  value  =  v  A 
preference  =  p  a  referent  =  r  • 

BBinar~y  Preference)) 
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Prefeiencesld  is  defined  to  allow  easy  access  to  the  identifier  slot  of  both 
unary  and  binary  preferences. 

Preferencesld  :  Preference  — >  Identifier 

Vp  :  Preference  • 

J  ((p  €  ran  UnaryP  ^  Preferencesld{p)  =  {UnaryP'" {p)).id)  A 

I  (p  €  inuBinaryP  =>  Preferencesld(p)  =  (BtnaryP~  (p)).id)) 

The  architecture  specifies  that  only  preferences  which  are  accessible  from 
the  most  recent  goal,  or  any  impasse  object,  should  remain  in  preference  mem¬ 
ory.  We  start  the  formal  definition  of  accessible  with  the  concept  of  connecting 
identifiers  over  a  universe  set  of  preferences.  Connected is  a  mapping 
that  takes  a  set  of  preferences  to  a  relation  between  identifiers.  Two  identifiers 
are  related  over  a  set  of  preferences  if  there  exists  a  preference  that  holds  the 
first  identifier  in  its  id  slot  and  the  second  in  its  value  or  referent  slot. 

Connectedp^gf^^^j^^g  ?  Preference  —  (Identifier  <-*  Identifier) 


'i  P  :  P  Preference-,  l,r  :  Identifier  • 


((p  €  ran  UnaryP  => 

{  UnaryP" (p)). id  =  /  A  (UnaryP'~{p)).value  =  r)  A 
(p  €  ran  BinaryP  => 

!  (3  6:  BinaryPreference  ;  6  =  BinaryP" (p)  • 

I  6. id  =  1  A  (b. value  =  r  v  b. referent  =  r))))) 

The  connection  formed  is  roughly  analogous  to  a  directed  edge  in  a  graph; 
here  each  unary  preference  would  be  viewed  as  an  attribute  labeled  edge  from 
id  to  value,  and  each  binary  preference  would  be  viewed  as  constructing  two 
attribute  labeled  edges  from  id  to  value  and  from  id  to  referent.  However,  the 
correspondence  is  not  very  natural  because  the  node  set  of  a  graph  of  preferences 
would  also  have  to  contain  all  of  the  constants.  Soar  allows  only  identifiers  to 
be  augmented  with  a  preference  (e.g.,  appear  in  the  id  slot  of  a  preference)  and 
so  the  graph  would  require  the  additional  constraint  that  only  identifier  nodes 
have  out  edges. 
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T^^Iptefeience  extends  the  concept  of  a  single  preference  connecting  pairs  of 
identifiers  to  a  path  of  preferences  connecting  sets  of  identifiers.  The  *  operation 
calculates  the  refiexive  transitive  closure  of  the  relation  Connectedp^g£^^g^^g{P) 
('Spi89j  102  ).  The  closure  is  then  imaged  ([Spi89r  101)  over  aU  of  the  identifiers 
in  the  start  set.  This  produces  an  operation  that  finds  all  of  the  identifiers 
connected  to  any  identifier  in  the  start  set  through  a  path  o'"  preferences.  The 
syntax  _(j_5  is  used  to  denote  the  image  of  a  function  on  a  set  of  argum“.its 
(fSpi89]  101).  The  image  of  a  function  on  a  set,  S,  is  the  set  of  the  function 
appUed  to  all  of  the  elements  of  S. 

:  P  Preference  — ►  (P  Identifier  — •  P  Identifier) 

VP:  P  Preference:  I  :  P  Identifier  • 

(^CWerence(^))(^)  =  ((Connected i  P))^^ 

0/Idpj,g^gj.gjjj,p  extracts  from  a  set  of  preferences  those  preferences  that  hold 
in  their  id  component  any  element  of  the  given  set  of  identifiers. 

Identifier  >  P  Preference  — •  P  Preference 

V  /  P  Identifier;  P  :  p  Preference  • 

C^^preference(^-  =  if  ^  Preferencesidip)  £  /} 


4.2  Working  Memory  Elements 

Soar  s  working  memory  is  a  set  of  elements  named  working  memory  elements. 
Working  memory  elements  have  an  id  component,  and  an  attribute  and  value 
components.  They  are  of  two  types:  those  that  are  a  copy  of  an  acceptable  pref¬ 
erence  for  a  context  slot  and  those  that  are  not  The  contexl_acceptaWe_prefereii 
component  holds  a  flag  of  the  free  type.  VesOriVo  to  distinguish  these  two  types. 

Yes  Or  No  :;=  I'es  No 

_  WME _ 

id  :  Identifier 

attribute ,  value  :  Symbol 

context  ^acceptable  ^preference  '■  YesOrNo 
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The  components  of  a  working  memory  element  is  the  set  of  its  identifier, 
attribute  and  value. 

WMEsComponents  :  WME  — *  P  E 

[  V  tn  ;  WME  •  WMEsComponenta[w)  =  {m. id,  w. attribute,  w. value} 

The  makeWME  constructor  is  defined  to  simplify  the  instantiation  of  work¬ 
ing  memory  element  schemas. 

j  makeWME  :  Identifier  x  Symbol  x  Symbol  x  YesOrNo  — •  WME 

!  V  I  :  Identifier-,  a,  v  :  Symbol;  c  :  YesOrNo  • 
makeWME {t,  a,  v,  c)  = 

(p.  WME  1  id  =  1  A  attribute  =  a  A  value  =  t;  A 
context  ^acceptable -preference  =  c  • 
eWME) 

Connected^'j^£  defines  the  notion  of  connectedness  of  identifiers  across  a 
single  working  memory  element  from  a  universe  set  of  working  memory  elements. 

Connected :  P  WME  — *  (Identifier  <-•  Identifier) 

j  V  W’  :  P  WME  ;  I,  r  :  Identifier  • 

(I,  r)  €  ( Connected W^)) 
j  (5  u)  :  H''  •  w.td  ~  I  A  w. value  =  r) 

^^^WME  extends  the  connectedness  definition,  in  the  same  way  '^dpxeleience 
did.  to  include  a  set  of  identifiers  and  any  path  of  wmes. 

:  P  WME  —  (P  Identifier  — >  P  Identifier) 

V  :  P  WME ;  /  :  P  Identifier  • 

{TCI^-j^j^{W)){I)  =  ((Connectedi(yjy^£;(  1T))*)(!/1) 

0{ld^r]^£  extracts  from  a  set  of  working  memory  elements,  the  ones  that 
contain  any  element  of  a  given  set  of  identifiers  in  their  id  component. 

I  ^  Identifier  x  P  WME  — •  P  WME 

V  /  :  P  Identifier  ;  W  :  P  WME  • 

OadwM£(I,W)=^  {w  :  W  \w.ide  1} 
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4.3  Temporary  Memory  Elements 

Temporary  memory  is  almost  a  disjoint  union  of  working  memory  elements  and 
preferences.  Elements  of  temporary  memory  are  of  type  TME,  a  disjoint  union 
type  of  Preference  and  WME.  Temporary  memory  is  not  exactly  a  disjoint  union 
of  working  memory  and  preference  memory.  The  one  distinction  is  that  the 
context  acceptable  preferences  from  preference  memory  are  copied  into  working 
memory  so  that  they  can  be  matched  by  productions  (see  Chapter  5). 

TME  ::=  PreferenceTME {(Preference))  \  WMETME {(WME)) 

A  TME’s  components  are  defined  to  be  the  components  of  the  underlying 
preference  or  working  memory  element. 

I  TMEsComponents  :  TME  — >  P  E 

V  t  :  TME  • 

((t  £  ra.n  PreferenceTME  => 

TMEs  Components  (t)  = 

PreferencesComponents{PreferenceTME'' {t)))  A 

'  (t  €  ran  WMETME  => 

I  TMEs  Components  (t)  = 

I  WMEsComponents(WMETME-{t)))) 

Connected  defines  connectedness  of  identifiers  through  a  single  tempo¬ 
rary  memory  element  over  a  universe  of  temporary  memory  elements. 

1  Connected :  P  TME  — *  {Identifier  *-*  Identifier) 

I  V  T  :  P  TME:  I,  r  :  Identifier  • 

(1,  r)  c  Connected j’^£{T)  o 

Connectedi^TMEi  WMETME^  p  n  ran  WMETME)  )u 

Connectedpjgf^jgj^^g{PreferenceTME''  {T  n  ran  PreferenceTME)) 

f'^^TME  the  notion  of  connectedness  to  sets  of  identifiers  over  paths 

of  temporary  memory  elements. 

!  TCIpj^p  :  P  TME  — ►  (P  Identifier  — *  P  Identifier) 

V  T  :  P  TME  ;  I  :  P  Identifier  • 

(TCJ2’3f£;(T))(/)  =  (( Connected  j'^£-(T))*)(1/1) 
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OfIdj’j^j£  extracts  the  subset  of  temporary  memory  elements  that  hold  one 
of  the  given  identifiers  in  their  id  slot. 

I  0{ldj’j^£  :  P  Identifier  x  P  TME  — ►  P  TME 

i  V  /  :  P  Identifier-,  T  :  P  TME  • 

!  Ofldj-j^f^il,  T)  = 

i  WMETMEIiOad-^^j^f£(I,  WMETME'  J T  n  ran  WMETME^)\iU 
j  Preference  TME  ,  Preference  TME"  J  T  n  ran  PreferenceTME\)\ 


4.4  Makes 

The  process  of  recall  from  long  term  memory  is  modeled  by  the  matching  of 
productions.  When  productions  match,  their  right  hand  sides  are  instantiated 
to  find  preferences  to  add  to  preference  memory.  The  right  hand  side  is  a  set  of 
makes.  The  makes  form  a  language  that  describes  how  productions  create  new 
preferences,  given  the  variable  bindings  from  the  left  hand  side  of  the  production 
match. 

The  data  type  schema,  UnaryMake  is  instantiated  to  create  a  unary  prefer¬ 
ence.  Makes  must  contain  a  variable  in  the  identifier  slot,  but  can  contain  either 
a  constant  or  a  variable  in  the  attribute  and  value  fields. 

, _ UnaryMake _ 

id  :  Variable 

attribute,  value  :  Variable  Or  Constant 
preference  :  Unary  Preference  Symbol 


A  unary  make’s  components  is  the  set  of  its  identifier,  attribute  and  value. 

Unary  Makes  Components  :  UnaryMake  — >  P  E 
V  u  :  UnaryMake  • 

j  UnaryMakesComponents{u)  =  {u.id,u. attribute, u.value} 

A  BinaiyMake  is  instantiated  to  make  a  binary  preference. 

. _ Binary  Make _ 

id  :  Variable 

attribute,  value  ;  Variable OrConstant 
preference  :  BinaryPreferenceSymbol 
referent  :  Variable  Or  Constant 
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A  binary  make's  components  are  the  set  of  its  identifier,  attribute,  value  and 
referent. 

i  Binary  Makes  Components  :  Binary  Make  — *  P  E 
V  h  :  BinaryMake  • 

BinaryMakesComponents{b)  =  {i.id,  b. attribute,  b. value,  b. referent} 

The  free  type  Make  is  defined  to  join  the  phrases  of  the  language  of  makes 
into  a  single  phrase. 

Make  ::=  Unary  M  ({Unary  Make))  \  Binary  M  Binary  Make)) 

A  make's  components  are  the  components  of  the  underlying  unary  or  binary 
make. 


i  MakesComponents  :  Make  — *  P  E 
V  m  :  Make  • 

i  ((rn  €  ran  UnaryM  => 

MakesComponents(m)  — 

U  nary  Makes  Components[  UnaryM  ~~  [m)))  A 
I  (m  £  ran  Binary M 

Makes  Components  (m)  = 

I  Binary  Makes  Components  ( B  inaryM  ''  ( tn ) ) ) ) 
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maJceUnaryMake  and  maJceBinaryMake  instantiate  copies  of  the  unary  or 
binary  make  schema,  and  wrap  them  in  the  make  free  type. 

j  make  Unary  Make  : 

Identifier  X  VariableOrConstanl  x  Variable  Or  Constantx 
UnaryPreferenceSymbol  — •  Make 
makeBinaryMake  : 

Identifier  x  VanableOrConatant  x  VariableOrConstantx 
I _ BmaryPreferenceSymbol  x  Variable  OrConstant  — •  Mo/fee 

I  Vi  :  Identifier;  a,  n  :  VariableOr Constant;  p  :  UnaryPreferenceSymbol  • 
j  make  Unary  Make{i.  a,  v,p)  = 

j  UnaryM  {{p.  Unary  Preference  \ 

I  id  =  i  A  attribute  =  a  A  value  =  v  A  preference  =  p  • 

j  6  Unary  Make)) 

j  Vi  :  Identifier;  a,v,r  :  VanableOrConatant;  p  :  BmaryPreferenceSymbol  • 
makeBmaryMake{i,  a,  V,  p,  r)  = 

BtnaryM {{p  BinaryPreference  \ 

\  id  —  i  A  attribute  =  a  A  value  =  v  a 

I  preference  —  p  A  referent  =  r  • 

j  6  Binary  Make)) 

Connected defines  connectedness  for  makes.  It  is  parallel  to  the  con¬ 
nectedness  for  preferences,  with  the  exception  that  makes  hold  constants  or 
variables  in  their  components  instead  of  constants  or  identifiers,  but  connected¬ 
ness  only  flows  through  variables. 

Connected :  P  Make  —*  (  Variable  ♦->  Variable) 

\  V  Af  :  P  Make;  l,r  :  Variable  • 
j  (1,  r)  €  ( Connected o 
{3  m  ■.  M  • 

((m  €  ran  UnaryM  => 

(3u  :  UnaryMake  \  u  =  UnaryM" [m)  • 
u.id  =  I  A  u. value  =  r))  A 
(m  E  ran  BinaryM  => 

(3  b  :  BinaryMake  \  b  =  BinaryM" {m)  • 
j  6. id  =  I  A  [b. value  =  r  V  b. referent  =  r))))) 
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extends  the  definition  of  connectedness  to  cover  sets  of  variables 
and  paths  of  makes. 

— >  (P  Variable  — *  P  Variable) 

'  V  M  :  P  Make ;  F  ;  P  Variable  • 

(T’CJMake(^))(^0  =  ((ConnectedJ^f^^(A/))•)J^ 

extracts  a  subset  of  a  set  of  makes  that  holds  any  element  from 
a  set  of  variables  in  their  identifier  slot. 

:  P  Variable  x  P  Make  — ►  P  Make 

V  V  ;  P  Variable  ;  M  :  P  Make  • 

:  OndM^j,,iV,M)  = 

I  {m  ;  M  I 

(m  €  ran  UnaryM  =>  { Unary M (m)). id  €  I')  v 
(m  €  ran  BinaryM  =>  [BinaryM'' {m)).id  6  V’)} 


4.5  Tests 

Productions  require  a  language  to  describe  how  to  match  against  the  contents 
of  working  memory.  The  terminal  phrases  of  this  language  are  called  Tests  and 
match  against  the  symbols  found  in’ the  fields  of  working  memory  elements. 

Test  is  defined  as  a  free  type,  both  to  construct  a  disjoint  union  and  to  allow 
tests  to  recursively  contain  tests  ([Spi89]  81-83).  Three  of  the  test  types  are 
constant,  and  five  are  constructed  from  arguments,  one  of  which  takes  a  set  of 
tests  as  arguments. 

Teat  ::=  BlankTest 
I  y  es  lest 
i  NoTesi 
I  E  quality  Test{{'L)) 
i  NotTest  {(■£)) 

I  SameTyp€Test{{'E)) 

I  Dtsjunctiv€Test{{P  Constant)) 

!  ConjunctiveTest{{P  Test)) 

As  a  production  matches,  it  constructs  a  binding  of  variables  to  symbols, 
much  like  an  environment  in  a  programming  language.  When  a  test  matches 
against  a  symbol,  if  the  test  is  constructed  using  a  variable  it  will  match  using 
the  binding  of  the  variable  instead  of  the  variable  itself. 

There  are  eight  types  of  tests. 
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1.  BlankTest  —  matches  any  symbol. 

2.  YesTest  —  matches  against  a  value  of  type  YesOrNo  that  is  a  Yes. 

3.  NoTest  —  matches  against  a  value  of  type  YesOrNo  that  is  a  No. 

4.  EqualityTest  —  matches  against  a  symbol  if  it  is  the  same  symbol  used  to 
create  the  equality  test,  or  the  binding  of  the  variable  used  to  create  the 
test. 

5.  NotTest  —  matches  against  a  symbol,  only  if  is  not  the  same  symbol 
used  to  create  the  NotTest,  or  not  the  same  symbol  as  the  binding  of  the 
variable  used  to  create  the  test. 

6.  SameTypeTest  —  matches  against  a  symbol  only  if  the  symbol  and  the 
constructing  argument  of  the  SameTypeTest  (or  its  binding)  are  both  in 
Identifier  or  both  in  Constant. 

7.  DisjunctiveTest  —  matches  a  symbol  only  if  it  is  in  the  se;  of  constants 
used  to  create  the  disjunctive  test. 

8.  ConjunctiveTest  —  matches  a  symbol  only  if  the  symbol  matches  all  of 
the  set  of  tests  that  were  used  to  create  the  conjunction. 

Although  Soar  could  support  recursive  conjunctive  tests  they  provide  no 
extra  matching  power  over  a  single  layer  of  conjunctions.  The  predicate  below 
constrains  all  conjunctive  tests  to  be  constructed  only  from  equality  tests,  not 
tests,  same  type  tests  and  disjunctions. 

V  ct  :  ran  Conjunctive  Test  • 

ConjunctiveTest''  (ct)  C 

(ran  EqualityTest  ran  NotTest'.^ 
ran  SameTypeTest  u  ran  DisjunctiveTest) 
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The  components  of  tests  are  collected  from  the  arguments  used  to  construct 
the  test. 


Tests  Components  :  Test  — ♦  P  L 
V  t  :  Test  • 

{(t  €  {BlankTest,  YesTest,  NoTest}  => 

Tests  Components  (t)  =  0)  A 
(<  £  inn  EqualityTest  => 

Tests  Components  (t)  =  {  E  quality  Te  st"  {t)})  A 
{t  £  inn  NotTesi  => 

!  TestsComponents{t)  =  {NotTest'' {t)})  a 

I  (<  6  tan  SameTypeTest  => 

Tests  Components{t)  =  {  Same  Type  Test '"(t)})  A 
!  ( <  €  ran  Disjunctive  Test  :=>■ 

j  Tests Components(t)  =  DisjunctiveTesf' (t))  A 

(t  £  ran  ConiunctiveTest  => 

i  ' 

Tests Components(t)  =  (J(  TestsComponents  (jConjunctiue  Tej<''(t)f ))) 

Soar’s  conditions  have  a  notion  of  a  positive  versus  a  negative  test.  A  positive 
test  is  one  that  checks  for  equality  with  a  constant  or  a  variable’s  binding,  and 
a  negative  test  is  one  that  does  not.  The  TestsPositiveComponents  mapping 
is  defined  to  extract  the  set  of  constants  and  variables  that  a  test  positively 
checks. 


TestsPositiveComponents  :  Test  —*  P  Symbol 
V  t  :  Test  • 

{(t  £  {BlankTest,  YesTest.  NoTest}i^ 
ran  SameTypeTest  o  ran  NotTest 
TestsPosiiiveComponents(t)  =  0)  A 
(<  t  ran  EqualityTest  => 

TestsPositiveComponents{t)  =  {EqualityTest" (t)})  a 
( I  £  ran  Disjunctive  Test  => 

TestsPositiveComponents(t)  =  DisjunctiveTest"  [t))  A 
(t  £  ran  ConjunciiveTest 
Tests  Positive  Components  {t)  = 

1J(  TestsPositiveComponents  d  Conjunctive  Te  st  ( t )[) ) ) ) 
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While  describing  operations  on  tests,  it  is  often  necessary  to  describe  one 
action  for  conjunctive  tests  and  another  action  for  all  other  types  of  tests.  The 
abbreviation  definition  ('Spi89  52)  below  defines  a  new  type  set.  SimpIeTest. 
that  simplifies  checking  whether  a  test  is  not  conjunctive. 

SimpIeTest  ==  (  Test  \  ran  ConjuncttveTest) 


4.6  WME  Tests 

Tests  are  composed  in  structures,  called  a  WMETest,  that  tests  against  a  work¬ 
ing  memory  element.  A  WMETest  matches  a  working  memory  element  if  and 
only  if  all  of  the  working  memory  element  test’s  tests  match  the  corresponding 
fields  of  the  working  memory  element. 

_  WMETest _ 

id ,  attribute  :  Test  {BlankTest.  YesTest,  NoTest} 

value  :  Test'  {YesTest.  NoTest} 

context  ^acceptable  ^preference  :  {YesTest,  NoTest} 


makeWMETest  instantiates  a  working  memory  element  test  given  its  four 
component  tests. 

makeWMETest  :  Test  \  [BlankTest.  YesTest,  NoTest}x 
Test  \  {  YesTest,  NoTest}  x 
Test  \{  Yes  Test ,  No  Test  }  x 

[YesTest,  .NoTest}  x  [YesTest,  NoTest}  — •  WMETest 

v  id  :  Test  \  [BlankTest.  YesTest,  NoTest}: 

attribute,  value  ■  Test  \  {  YesTest.  NoTest}: 
context  ^acceptable  ^preference  :  [YesTest.  NoTest}  • 
make  W  ME  Test(id.  attribute,  value,  context  ^acceptable  ^preference)  = 
(pid  :  {id},  attribute  :  [attribute}:  value  :  {uolue}; 
i  context -acceptable -preference  :  {context-acceptable-preference}  • 

!  e  WMETest) 

The  components  of  a  working  memory  element  test  are  the  components  of 
its  id.  attribute  and  value  fields. 

WMETestsComponents  :  WMETest  — »  P  Symbol 

v  wt  :  WMETest  • 

WMFTe.it.iCnmponentsIwt)  = 
y(  TestsComponents '^[■wt.td.  wt. attribute,  tut.  value};) 
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WMETestsPositiveComponents  extends  the  concept  of  a  positive  component 
to  the  level  of  a  working  memory  element  test. 


WMETestsPositiveComponents  :  WMETest 


P  Symbol 


V  vit  :  WMETest  • 

WMETestsPositiveComponents{wt)  = 

|J(  TestsPostttveComponents^{u)t.id,  wt. attribute,  iut.t)a/ue}[|) 


Two  working  memory  element  tests  are  connected  if  either  of  their  identifier 
tests  share  positive  components,  or  the  first  test’s  value  test  shares  components 
with  the  second  one’s  id  test. 


_  Connected -  '■  WMETest  <-*  WMETest 

V  wt\,  wti  :  WMETest  • 

wti  Connected  wt2  o 

(( TestsPositiveComponents{wt\.id)C 

TestsPositiveComponents{wl2  id))  3;  0  V 
( Tests PosttiveComponents(  wti.value)r 
TestsPositiveComponents(tut2  id))  ±.  0) 


4.7  Conditions 

Soar’s  productions  check  working  memory  for  the  existence  of  elements  matching 
working  memory  element  tests,  but  they  must  also  check  if  working  memory  does 
not  contain  matching  patterns  of  elements.  Working  memory  element  tests  are 
bundled  into  structures,  called  Conditions,  that  match  on  the  existence  and 
non-existence  of  patterns  of  elements. 

PositiveConditions  match  when  there  exists  a  working  memory  element  that 
their  WMETest  matches.  NegativeCondition  match  the  non-existence  of  a  el¬ 
ement  that  matches  their  WMETest.  NegativeConjunctiveConditions  match 
when  all  of  their  conditions  feiil  to  simultaneously  match  working  memory. 

Condition  :;=  PositiveCondition({WMETest}) 

I  NegativeCondttion{{WMETest)) 
i  NegattveConjuncttveCondition({P Condition)) 
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Conjunctive  negations  are  restricted  to  contain  at  least  one  positive  condi¬ 
tion. 


V  c  ;  tan  Negative  ConjtiticiiveCondition  • 

3  cs  :  P  Condition  |  C3  =  NegativeConjunctiveCondition’' (c)  • 
tan  PositiveCondition  n  cs  9^  0 

While  specifying  operations  on  conditions  cased  by  type,  it  is  convenient 
to  have  a  sub-type  of  conditions,  SimpleCondition,  that  excludes  the  negative 
conjunctive  conditions. 

SimpleCondition  ==  ran  PositiveCondition  u  ran  Negative  Condition 

ConditionsComponents  extracts  the  components  of  a  condition  from  its 
working  memory  element  tests  or  recursively  from  its  embedded  conditions. 

ConditionsComponents  :  Condition  — ►  P  Symbol 

V  c  :  Condition  • 

((c  €  ran  PositiveCondition  => 

ConditionsComponents(c)  = 

!  IVME Tests Components(Posttive Condition'’ {c)))  A 

(c  €  ran  Negative  Condition  =?• 
i  ConditionsComponents(c)  = 

'  WMETestsComponents{NegativeCondition''(c)))  A 

(c  €  i&n  NegativeConjunctiveCondition  => 

Conditions  Components  (c)  = 

U  ( Conditions  Components  { NegativeConjunctiveCondition  ^  ( c )[ ) ) ) 

The  positive  components  of  a  condition  are  defined  to  be  all  of  the  positive 
components  of  its  working  memory  element  test  or  embedded  conditions. 

Conditions  Positive  Components  :  Condition  — •  P  Symbol 
\  _ _ 

V  c  :  Condition  • 

((c  €  ran  PositiveCondition  => 

ConditionsPositiveComponents(c)  ~ 

WMETestsPositiveComponentsl^PositiveCondition"  [c]))  z' 

(c  €  ran  Negative  Condition  ^ 

ConditionsPositiveComponents{c)  = 
j  WMETestsPositiveComponents{NegativeCondition'' [c)))  ^ 

[c  £  Tun  NegativeConjunctiveCondition  => 

^  Conditions  Positive  Components  {c)  = 

i  lj( ConditionsPositiveComponents ^NegativeConjunctiveCondition' [c)[))) 

Soar  constrains  the  conditions  of  the  left  hand  side  of  the  production  to 


48 


be  connected,  and  chunking's  inner  loops  calculate  the  transitive  closures  of 
conditions.  Unfortunately,  negated  conditions  and  conjunctive  negations  do  not 
allow  the  definition  of  connectedness  of  conditions  to  be  parallel  with  those  of 
preferences,  working  memory  elements,  temporary  memory  elements  and  makes. 

Connected defined  to  connect  sets  of  conditions  to  sets  of  con¬ 
ditions,  instead  of  connecting  pairs  of  identifiers  over  a  universe  of  conditions. 

This  allows  the  definition  to  support  Soar's  use  of  multiple  starting  conditions 
to  connect  into  a  conjunctive  negation. 

Two  sets  of  conditions,  A  and  B,  are  connected  if  and  only  if  B  holds  a 
positive  condition,  b,  whose  WMETest  is  connected  to  the  WMETest  of  any 
positive  condition  in  A,  and  A  union  the  set  of  b  is  connected  to  B’s  other 
conditions.  Similarly,  a  negated  condition,  b  in  B,  is  connected  to  A  if  there  is 
a  positive  condition  in  A  whose  WMETest  connects  to  b,  and  A  connects  to  the 
remaining  elements  of  B.  Notice  that  only  positive  conditions  in  A  may  connect 
to  a  elements  of  B. 

A  set  of  conditions,  A,  is  connected  to  a  set  of  conditions,  B,  containing  a 
conjunctive  negation,  b  if  and  only  if  A  connects  to  all  of  the  sub-conditions  of 
b  and  A  union  the  set  of  b  connects  to  B’s  remaining  conditions.  This  connects 
any  conjunctive  negation  whose  sub-conditions  are  all  connected  to  A,  either 
directly  or  through  a  path  in  the  sub-conditions. 

1  _  Connected _  ;  P  Condition  — +  P  Condition 
V  A  :  P  Condition  •  A  Connected 0 

I  V  A,  B  :  P  Condition  • 

A  Connected(^o„jjt,-o„  B  o 
{3  b  :  B  • 

{b  c  ran  PositiveCondition  => 

{3  a  :  A  • 

PositiveCondiiion''{a)  Connected-\^’j^£'Yest  PositiveCondition'’  [b)))  A 
{b  <E  ran  NegativeCondition  ^ 

I  (5  a  :  A  • 

I  PositiveCondition" {a)  Connected-^Yj^^j-ggf  NegativeCondition" {b)))  a 

j  (6  €  inn  NegativeConjunctiveCondition  ^ 

I  (A  Connected NegativeConjunctiveCondition"{b)))  A 

i  Au{6}Conrected(;ondition^ 


49 


T^^Condition  transitively  closes  a  set  of  conditions  S  over  a  universe  U.  The 
definition  constructs  the  closure  using  the  maximal  set  under  the  set  inclusion 
ordering.  The  image  of  a  form  of  the  reflexive  transitive  closure  could  be  used, 
but  it  would  be  cumbersome  due  to  Connected^^^jj^j^^'s  different  signature. 

I  TCIcondition  '  ^  Condition  x  P  Condition  — *  P  Condition 

\  V  5,  b'’  :  P  Condition  • 

j  3C  :P  U  \ 

;  (5  Connected  Condition 

i  (V  5  :  P  .  5  Connected  Condition  B  ^  B  Z  C)  • 

TCIcondhioniS.C)=C 

C{Id Condition  extracts  the  positive  and  negative  conditions  of  a  set  that 
match  any  constant  in  their  identifier.  It  does  not  extract  the  negative  con¬ 
junctive  conditions  that  hold  the  set  of  symbols  in  their  identifier  because  this 
requires  a  fuU  recursive  definition  of  connectedness.  Where  this  is  required. 
Ofidcondition  used  in  conjunction  with  Connected  Condition 
connect  into  the  conjunctive  negations. 

Ofldcondition  •  P  ^  ^  P  Condition  — »  P  Condition 
V  7  :  P  L;  C  ;  P  Condition  • 

I  ^^^Conditioni^ '  ~ 

{c.C.Si:!* 

:  (c  €  ran  Positive  Condition  => 

:  €  TestsPositiveComponents{{PositiveCondition'' {c)) .id))  r- 
(c  €  ran  Negative  Condition  => 

j  t  TestsPositiveComponents((NegativeCondition''  {c)).id))} 


4.8  SP 

Productions  are  Soar’s  model  of  long  term  memories.  They  match  against  the 
contents  of  working  memory,  instantiate  and  fire  to  augment  support  memory 
with  preferences. 
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Soar's  definition  of  match  requires  that  every  variable  that  is  tested  against 
(with  NotTest,  or  SameTypeTest)  must  be  bound  in  some  condition  (with  an 
EqualityTest).  TestedVatiablesBound  is  a  predicate  that  checks  that  the  vari¬ 
ables  a  condition  tests  against  are  all  in  .he  set  of  bound  variables 

Tested VariabJesBound  _  :  P(  Condition  x  P  Variable) 

bound  ■  P  Vartablt]  c  :  Condition  • 

TestedVatiablesBound  {c,  bound) 

(c  €  ran  Positive  Condition  => 

{CondiiionsComponents[c)  Variable)  C  bound)  ^ 

(c  t  tan  NegativeCondition  =- 

(  Conditions Compotienls (l)  Variable)  C 

[bound  -J  (CondttionsPosittveComponenis{c)  ^  Variable)))  A 
I  (c  €  tan  NegativeConjunctiveCondition  => 

(3  cs  :  {NegativeConjunctiveConditici^ [c)}  • 

(3  bv  :  P  Variable  i 
hv  =  bounds 

(|J( '  nditionsPositiveCoTnponents(\cs  ^  ran  PositiveCondition) ) 
Variable)  • 

(V  c  :  CJ  •TestedVatiablesBound  (c,  feti))))) 


51 


Soar’s  productions,  SPs,  have  a  name,  a  set  of  left  hand  side  conditions,  Ihs, 
that  describe  how  they  match  against  working  memory  and  a  right  hand  side 
set  of  actions,  rhs.  The  Ihs  must  contain  at  least  one  positive  condition,  or  the 
rhs  would  have  no  variables  bound  to  use  in  make  actions.  Each  condition  may 
only  test  against  variables  that  are  bound  with  a  equality  test  somewhere  on 
the  left  hand  side. 

^SP _ 

I  name  :  Symbol 
I  //i4  :  P  j  Condition 
j  rhs  :  P  Make 
\  roots  :  P  Variable 
i - 

i  z  c  :  Ihs  •  c  ^  tan  Positive  Condition 

'i  c  :  Ihs  •  Conditions Components{c)  n  Identifier  =.  0 
roots  = 

I  {f  :  \J{ConditionsPositiveComponents^{lhs  r]  Ta.n  PositiveCondition)^) 
!  {z  c  :  Ihs  r  ran  P ositiveCondition  • 

j  V  €  TestsPositiveComponents{{PositiveCondition~~ [c)). value))} 

'  Ihs  =  TCIconditioni^^^Conditioni''°°^^^ 

I 

[  z  boundvariables  :  P  Variable  \ 
boundvariables  = 

(|J(  ConditionsPositiveComponents^lhs  n  ran  PositiveConditionl) 
n  Variable )  • 

j  (V  c  :  Ihs  •TestedVariablesBound  (c,  boundvariables)  A 
I  rhs  —  0{Id^g^j^g{TCIj^j^j^^{rhs)(boundvariables).  rhs)) 


Conditions  are  stored  in  two  places  in  Soar:  in  productions  they  describe 
when  and  how  productions  match,  and  in  chunking  they  record  which  patterns 
their  productions  matched  against.  Chunking’s  conditions  may  have  matched 
against  identifiers  and  so  they  are  instantiated  with  identifiers  to  record  the 
match.  However,  productions  are  constrained  not  to  use  identifiers  in  their 
match,  otherwise  they  would  be  terribly  specific  to  the  set  of  identifiers  in  use 
(except  for  internal  chunks). 

A  root  of  a  production  is  an  identifier  that  is  not  positively  tested  in  any  value 
of  the  positive  conditions.  Soar  constrains  these  variables  to  match  against  goal 
or  impasse  identifiers.  All  of  the  conditions  of  the  Ihs  must  be  in  the  transitive 
closure  of  the  roots;  this  ensures  that  productions  only  match  working  memory 
elements  which  are  in  the  transitive  closure  of  the  context  stack  or  an  impasse. 

The  right  hand  side  is  also  constrained  to  be  transitively  closed  over  the 
bound  variables  of  the  left  hand  side.  This  ensures  that  the  instantiations  only 
make  new  preferences  that  are  accessible  from  a  goal  or  impasse. 
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makeSP  is  used  to  construct  a  new  production  data  schema.  It  takes  only 
three  arguments,  the  name,  the  left  hand  side  and  the  right  hand  side,  as  the 
roots  are  a  derived  component  of  the  left  hand  side. 

!  makeSP  :  Symbol  x  Condition  x  P  Make  —*  SP 

V  name  :  Symbol,  Ihs  :  Condition;  rhs  :  P  Make  • 

roots  :  P  Variable  \  SP  • 
makeSP{name,  Ihs,  rhs)  =  BSP 

The  components  of  productions  are  all  of  the  components  of  its  left  hand 
side  and  the  components  of  its  tight  hand  side. 

SpsComponents  :  SP  — *  P  E 

V  jp  :  SP  • 

SpsComponents  (sp)  = 

[J{  Conditions  Components  ^sp.lhs^  U  M akes  Components  ^sp.rhs^) 
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Chapter  5 


Recognition  Memory 


Recognition  memory  is  where  Soar  holds,  processes  and  acquires  long  term 
memories.  Long  term  memories  are  stored  as  productions  that  match  against 
short  term  memories  in  working  memory.  Recognition  memory  matches  the 
productions  against  working  memory,  stores  the  matches,  instantiates  matches 
to  produce  new  preferences,  and  calculates  support  for  preferences  and  chunks. 

The  chapter  is  divided  into  nine  sections: 

•  Section  5.1  Bindings  —  introduces  bindings  that  map  variables  to  values 

•  Section  5.2  Matching  —  defines  how  productions  match  against  working 
memory 

•  Section  5.3  Instantiation  —  specifies  how  matches  are  instantiated 

•  Section  5.4  Goal  Operations  —  defines  some  operations  on  Decide's  goal 
stack  for  use  by  support 

•  Section  5.5  Chunking  —  defines  chunking.  Soar’s  learning  mechanism 

•  Section  5.6  Slots  —  defines  the  concepts  of  a  slot. 

•  Section  5.7  Recognition  Memory’s  State  —  constructs  the  state  of  recog¬ 
nition  memory 

•  Section  5.8  Support  —  specifies  how  instantiations  support  preferences 
and 

•  Section  5.9  Preference  Phase  Operations  —  defines  the  state  machine  for 
recognition  memory’s  control  loop,  called  preference  phase. 
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5.1 


Bindings 

Soar’s  productions  match  against  working  memory  using  a  binding  of  the  pro¬ 
duction’s  variables  to  symbols.  Bindings  are  similar  to  environments  in  pro¬ 
gramming  languages.  In  Soar,  bindings  are  modeled  as  partial  functions  from 
variables  to  symbols. 

Binding  =—  Variable  ■**  Symbol 

When  productions  match,  they  check  that  there  is  no  possible  way  to  instan¬ 
tiate  their  negated  conditions  to  allow  them  to  match  working  memory.  The 
negative  conditions  must  not  be  able  to  add  bindings  for  their  local  variables 
that  allow  them  to  match  working  memory  elements.  To  formabze  the  match 
of  negative  and  negative  conjunctive  conditions,  we  define  the  concepts  of  two 
bindings  being  consistent,  a  binding  covering  a  set  of  variables,  and  one  binding 
being  a  consistent  extension  of  another. 

Two  bindings  are  consistent  if  they  both  bind  every  variable  that  they  share 
to  the  same  symbol.  A  binding  covers  a  set  of  variables  if  it  gives  a  binding 
to  every  variable  in  the  set.  A  binding.  A,  is  a  consistent  extension  of  another 
binding,  B,  if  it  is  consistent  with  it  and  A  possibly  binds  variables  that  B  does 
not. 

'  _  Consistent  ConsistentExtension  _  :  Binding  — >  Binding 
_  Covers  _  -.  Binding  «  P  E 

a,  b  :  Binding  • 

(a  Consistent  b)  o 

(V  t)  :  dom  a  n  dom  6  •  a(t))  =  b{v)) 

!  V  6  :  Binding  •  V  r  :  P  Variable  • 

I  b  Covers  r  o  r  C  dom  6 

I 

i  V  a.  i  .  Binding  • 

o  ConsistentExtension  b  o 

(a  Consistent  b  A  (dom  b  C  dom  o)) 


5.2  Matching 

The  core  result  of  matching  a  production  against  working  memory  is  a  corre¬ 
spondence  between  the  positive  conditions  of  the  production  and  the  working 
memory  elements  they  match.  In  this  section,  we  define  how  a  test  matches  a 
symbol,  and  how  a  working  memory  element  test  matches  a  working  memory 
element.  We  use  this  to  define  the  concept  of  a  match  to  a  production,  and  then 
define  when  a  match  is  consistent  with  the  contents  of  working  memory. 
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5.2.1  Tests  Matching  Symbols 

A  test  can  match  a  symbol,  under  a  binding,  in  one  of  six  ways. 

1.  The  test  can  be  the  blank  test,  which  matches  any  symbol. 

2.  Equality  tests  only  match  a  symbol.  A,  if  their  argument  is  A,  or  a  variable 
bound  to  A.  The  0  notation  is  Z’s  way  of  function  overriding  (iSpi89l 
108).  (a  0  b)(z)  ic  b{x)  if  j  G  dom  b  or  a{x)  if  i  G  dom  a  and  undefined 
otherwise.  The  (idS)  is  the  identity  function  on  E  ([Spi89]  97).  The 
overriding  of  (id  E)  with  the  binding,  b,  produces  a  function  that  returns 
the  binding  of  the  equality  test’s  variable,  or  the  equality  test’s  constant. 

3.  Not  tests  match  a  symbol,  A,  only  if  their  symbol  or  variable’s  binding  is 
not  equal  to  A. 

4.  Same  type  tests  match  a  symbol.  A,  against  their  symbol  or  variable’s 
binding,  B,  only  if  A  and  B  are  both  identifiers  or  both  constants. 

5.  A  disjunctive  test  matches  only  constants  that  are  elements  of  the  dis¬ 
junction’s  argument  set. 

6.  Conjunctive  tests  match  a  symbol  only  if  the  symbol  matches  all  of  the 
conjunction’s  sub-tests. 

j  P {Binding  x  Test  x  Symbol) 

V  6  :  Binding-,  t  :  Test-,  v  :  Symbol  • 

((<  =  BlankTest)  V 

(t  G  ran  EqualityTest  A  v  —  ((id  E)  0  b){  Equality  Test''  {t)))  V 
(t  G  ran  NotTest  a  v  at  ((id  E)  ©  b)(NotTe.<i('' {i)))  v 
(t  G  tan  SameTypeTest  a 

j  (3  v2  :  {((id  Symbol)  0  b){SameTypeTest''  {t))}  • 

1  €  Identifier  A  «2  G  Identifier)  v 

j  (v  G  Constant  A  v2  €  Constant))))  A 

\  (t  G  tan  DisjunctiveTest  A  »  G  DisjunctiveTest~~(t))  V 

I  (t  G  ran  ConjunctiveTest  A 

(V  su6t  :  ConjunctiveTest'' {t)  •Matches^^^^^j  (b,subt,  *')))) 
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A  working  memory  element  test  matches  a  working  memory  element  if  its 
id,  attribute,  value  and  context  acceptable  preference  fields  match  the  element's 
test’s  id.  attribute,  value  and  context  acceptable  preference  test. 


Matches _  :  ^(Binding  x  WMETesi  x  WME) 


V  h  :  Binding;  wt  :  WMETesi;  w  :  WME  • 
Matches^Mp^“*  (6,  wi,  w)  <=> 

( Matches (6,  wt.id,  w.td)  A 
Matches (b,  wt. attribute,  w . attribute)  A 
Match (b,  wi. value,  w. value)  A 

{wt.  context  ^acceptable  ^preference  =  TesTest  => 
w .  context  ^acceptable -preference  =  les)  A 
{wt.  context -acceptable -preference  =  No  Test  => 
w .  context -acceptable -preference  =  No)) 
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5.2.2  Matches 

The  full  result  of  a  production  matching  is  recorded  in  a  match  schema.  The 
match  contains:  the  production  that  matched,  the  correspondence  between 
its  positive  conditions  and  the  working  memory  elements  it  matched,  called  a 
matching,  the  binding  that  allows  this  correspondence,  and  the  set  of  matched 
working  memory  elements. 

The  matching  is  actually  a  correspondence  between  the  positive  conditions 
and  working  memory  element,  number  pairs.  As  each  working  memory  element 
could  be  added  to  working  memory,  later  removed  and  the  re-added,  we  identify 
each  instance  of  a  working  memory  element  uniquely  using  a  natural  number 
tag. 


_ Match _ 

j  production  :  SP 

matching  :  ran  Positive  Condition  (  WME  x 
binding  :  Binding 
'  Ihs  :P  WME 

dom  matching  =  {production. Ihs  O  ran  PositiveCondition) 

Ihs  =  /irjtjran  matchingl 
1  dom  binding  = 

[J{ConditionsPosittveComponentsliproduction.lhs  ran  PosittveCondition\) 
I  n  Variable 

j  V  c  :  dom  matching  • 

Matches (binding.  PositiveCondition"  [c] ,  firsii  matching{  c))) 

makeMatch  constructs  a  new  match  given  the  production  and  the  matching 
between  the  positive  conditions  and  the  working  memory  elements  that  they 
matched.  The  match’s  binding  and  left  hand  side  are  uniquely  determined 
by  the  production  and  the  matching,  so  they  are  not  required  arguments  to 
construct  a  match. 

j  makeMatch  : 

SP  X  (lan  PositiveCondition  -«•  (WME  x  N))  — *  Match 
V  production  :  SP; 

matching  :  (ran  PositiveCondition  ( WME  x  M))  • 
dj  binding  :  Binding;  Ihs  :  P  WME  ,  Match  • 
i  makeMatch(production,  matching)  —  9Match 
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5.2.3  Matching  against  Working  Memory 

The  definition  of  match  checks  the  correspondence  between  the  positive  condi¬ 
tions  and  the  working  memory  elements  that  they  matched,  but  it  makes  no 
statement  that  these  elements  must  be  in  working  memory.  Nor  does  it  require 
that  the  negative  conditions  do  not  have  any  matches  in  worldng  memory.  We 
rectify  this  by  constraining  how  a  condition  matches  against  the  contents  of 
working  working  memory 

Matches^^j^*^^**^"  takes  a  binding,  a  condition  and  a  set  of  working  memory 
elements,  and  checks  if  the  condition  matches  working  memory.  A  positive 
condition  matches  working  memory  if  there  is  a  element  in  working  memory 
that  its  WMETest  matches  under  the  binding.  A  negative  condition  matches 
against  working  memory  if  there  is  no  way  to  consistently  extend  the  binding  to 
cover  the  variables  of  the  negated  condition  and  then  find  an  element  in  working 
memory  whose  test  matches.  A  negative  conjunctive  condition  matches  working 
memory  if  there  is  no  way  to  extend  the  binding  and  to  match  all  of  its  sub¬ 
conditions  against  working  memory. 

_  :  P(BindtTig  x  Condition  x  P  H'M^) 

V  6  :  Binding-,  pc  :  ran  PositiveCondition.  WM  :  P  WME  • 

(b,pc,  H'Af)  o 

W  :  WM  • 

[b,  PositiveCondition"  {pc),  w]) 

\  V  6  :  Binding',  nc  :  ran  Negative  Condition',  WM  ;  P  WME  • 
Matcliesg?^'^^^'*'^  (6.  nc,  H'M)  o 
-  ( 5  ni  :  Binding 

nb  Consister (Extension  b 

\  nb  Covers  {ConditionsCo'mponents(nc)  ^  Variable)  • 

I  (=  w  :  WM  • 

i  Matches^.^£^'^®^  (nb,  NegativeCondition"  (nc),  iv))) 

j  V  6  ;  Binding;  ncc  :  ran  NegativeConjunctiveCondition-,  WM  :  P  WME  • 
t  Matches^^*^*^'®"  (ft,  ncc,  H''M)  o 
j  (3  nft  :  Binding  ; 

I  nb  Consistent  Extension  ft  a 

I  nb  Covers  (ConditionsComponents{ncc)  Variable)  • 

[  Vc  :  NegativeConjiinctiveCondition'~{ncc)  • 

Matches (nb,  c,  WM)) 
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A  match  is  satisfied  by  working  memory  if  and  only  if  all  of  its  conditions 
match  against  working  memory  under  the  match’s  binding,  and  the  elements 
they  match  have  the  current  working  memory  numbering,  i.e.,  the  elements  are 
the  copies  that  are  currently  in  memory. 

i  Matches^^^^^  _  :  P{Match  x  P  WME  x  (  WME  y**  \)) 

V  m  :  Match'  WM  :  P  WME  • 

MatcJies^^*'^  (m,  WM ,  WM#)  O 
[  (V  c  ;  m. production. Ihs  • 

;  Matches^^‘^‘°’^  (m. binding,  c,  WM)  A 

WM  if^(m.matching(c))  =  second{Tn.Tnatching{c))) 


5.3  Instantiation 

When  Soar  finds  a  match  for  a  production,  it  instantiates  it  and  adds  it  to 
instantiation  memory.  The  act  of  instantiation  generates  an  instantiated  version 
of  the  match’s  production’s  conditions  and  a  set  of  preferences  from  the  match’s 
production’s  right  hand  side  makes.  Soar  adds  the  support  conferred  by  the 
instantiation  to  each  preference’s  entry  in  support  memory.  Soar  checks  the 
support  of  preferences  to  decide  how  to  change  preference  memory.  Soar  then 
passes  the  preference  memory  changes  to  decide,  which  changes  the  contents  of 
working  memory  to  reflect  the  new  contents  of  preference  memory. 

This  section  defines  how  a  match’s  production’s  conditions  are  instantiated, 
and  then  how  a  match’s  production’s  right  hand  side  is  instantiated,  and  then 
the  instantiation  data  structure  schema. 


5.3.1  Instantiating  a  Match’s  Production’s  Conditions 

This  section  defines,  in  bottom-up  order,  seven  recursive  functions  that  instan¬ 
tiate  the  conditions  of  a  match’s  production  using  the  match’s  binding.  The 
end  result  is  a  partial  function,  called  a  matching,  that  maps  the  conditions  of 
the  production  to  their  corresponding  instantiated  condition. 

InstantiateVariableOrConstant  returns  a  variable’s  binding,  if  it  is  bound, 
or  returns  the  variable,  if  it  is  unbound,  and  otherwise  returns  a  constant. 

InstantiateVariableOrConstant  : 

(  Variable  o  Constant)  x  Binding  —  S-ymbol 

V  cv  :  Constant  ^  Variable:  b  :  Binding  • 

Instantiate  VariableOrConstant(cv ,  b)  =  ((id  S)  ©  b){cv) 
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InstajitiateSimpIeTest  returns  tests  with  no  arguments  unmodified.  Equality, 
same  type  and  not  tests,  it  destructures,  instantiates  their  variable  or  constant 
and  returns. 

j  InstantiateSimple Test  :  SimpleTest  x  Binding  — ►  SimpleTest 
j  V  t  ;  SimpleTest'  b  :  Binding  • 

I  {((t  =  BlankTest  v  t  =  YesTest  V  t  =  NoTest  V  t  c  tan  DisjnnctiveTest) 
j  =>  InstantiateSimpleTest{t,b)  =  t)  A 

j  (t  €  tan  Equality  Test  => 
j  InstantiateSimpleTest{i,  b)  = 

EqualityTest{InstantiateVa'nableOrConstant{EqualityTest^ (t),  b)))  A 
!  (t  G  ran  SameTypeTest  => 
j  InstantiateStmpleTest(t,  b)  = 

Same  Type  Test  ( Instantiate  VariableOrConstant{  Same  Type  Test''{t),b)))  A 
(t  G  ran  NotTest 
InstantiateSimple Test(i.  b)  = 

NotTest{InstantiateVanableOrConstant{NotTest'' (i),  6)))) 

InstantiateSetOfSimpleTests  iterates  the  simple  test  instantiator  across  a  set 
of  tests. 

i  InstantiateSetOfSimpleTests  : 

P  SimpleTest  x  Binding  —  ?  SimpleTest 

I  I  ■ 

I  V  5  :  P  SimpleTest',  b  :  Binding  • 

((S  =  0  =?>  InstantiateSetOfSimpleTests{S ,  6)  =  0)  A 
!  (5  5i:  0  => 

(E  i  :  5  • 

InstantiateSetOfSimpleTests(S ,  b)  = 

{InstantiateSimpleTest{s,  b)}u 
InstantiateSetOfSimpleTests(S  \  {s}.  b)))) 
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InstantiateTest  instantiates  a  test  by  calling  either  instantiate  simple  test, 
or  by  unpacking  a  conjunctive  test,  instantiating  its  component  tests  and  re¬ 
packing. 


InstantiateTest  :  Test  x  Binding  — >  Test 

V  t  :  Test',  b  :  Binding  • 

((i  ^  ran  ConjunctiveTest 
InstantiateTest(t,b)  = 

InstantiateSimpleTest{t,  b))  A 
(t  €  ran  ConjunctiveTest  ^ 

InstantiateTest(t,  b)  = 

Conjunctive  Test( 

InstantiateSetOfSimpleTests(  ConjunctiveTest"'  {t),  b)))) 

InstantiateWMETest  instantiates  a  working  memory  element  test  by  instan¬ 
tiating  its  component  parts,  and  giving  the  new  test  the  same  context  acceptable 
preference  test. 

InstantiateWMETest  :  WMETest  x  Binding  — >  WMETest 

V  w  :  WMETest  ;  b  :  Binding  • 

InstantiateWMETest(w ,  b)  = 

(p,  id  :  {InstantiateTestiw.id.  6)}  • 

(p  attribute  :  {InstantiateTest(w .attribute,  b)}  • 

[p  value  .  {In3tantiateTest{w  value,  b)}  • 

{p  WMETest  \ 

context -acceptable  ^preference  = 
w .context -acceptable -preference  • 
eM’METest)))) 
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InstantiateCondition  and  InstantiateSetOfCondhions  recurse  through  con¬ 
ditions  instantiating  their  component  working  memory  element  tests  or  condi¬ 
tions.  Z  requires  that  they  are  defined  in  a  single  axiomatic  definition  to  allow 
them  to  be  mutually  recursive. 

InstantiateCondition  :  Condition  x  Binding  —*  Condition 
Instantiates etOf Conditions  :  P  Condition  x  Binding  — *  P  Condition 

V  c  :  Condition-,  b  :  Binding  • 

((c  G  tan  PositiveCondition  => 
j  Instantiate C ondition{c,  h)  = 

!  PositiveCondition[InstantiateWMETest{PositiveCondition'' [c],  6)))  a 

I  (c  G  ran  Negative  Condition  => 

Instantiate Condition(c.  b)  = 

Negative  Condition { Instantiate  WME Test(Negative  Condition  ( c ) ,  6 ) ) )  A 
(c  G  ran  NegativeConjunctiveCondition  => 
i  InstantiateCondition{c,b) — 

Negative  Conjunctive  Condition 
(InstantiateSetOf Conditions 

I  {NegativeConjunciiveCondition'' (c),  b)))) 

j  V  5  :  P  Condition-,  b  :  Binding  • 
j  ((5  =  0  =>  Instantiate SetOf Conditions{S ,  6)  =  0)  A 
(5yi0=> 

;  (3  i  :  s  . 

j  InstantiateSetOf Conditions(S ,  b)  = 

I  {lnstantiateCondition{s,b)}u 

InstantiateSetOfConditions{S  \  {«}.  6)))) 
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ListantiateConditionsWME  instantiates  a  condition  that  corresponds  to  the 
working  memory  element  that  a  positive  condition  matched. 

Inatantiaie  Conditions  W ME  :  WME  — *  Condition 
V  VI  :  WME  • 

{{vi.  context  ^acceptable  ^preference  —  Yes  => 

Instantiate  Conditions  WME  (w)  = 

Positive  Condition( 

make  WMETest(Equality  Test{  w.id),  Equality  Test[  w . attribute), 
Equality  Test(w .  value ) ,  Yes  Test) ) ) 

A 

(w  .context -acceptable -preference  =  Yes  => 
InstantiateConditionsWME{w)  = 

Positive  Condition( 

make  WME  Test{Equality  Test{vi.id),  Equality  Test[w.  attribute) , 
E quality Test{w .value),  NoTest)))) 
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InstantiateConditionMalching  instantiates  a  set  of  conditions  under  a  bind¬ 
ing  to  produce  a  partial  function  that  maps  each  of  the  conditions  to  their  in¬ 
stantiation.  The  positive  conditions  are  mapped  to  a  simple  instantiated  version 
of  the  working  memory  element  that  they  matched.  It  contains  an  equality  test 
for  each  value  in  the  element  and  the  appropriate  context  acceptable  preference 
test.  The  negative  conditions  are  recursively  instantiated  to  retain  their  test 
structures,  but  have  their  variables  replaced  with  identifiers.  This  retains  max¬ 
imal  inforiaatxon  about  their  matching  which  can  be  utilized  when  the  chunk  is 
buUt. 


Instantiate  ConditionMatchxng  : 

[tan  PositiveCondition  {WME  x  l^))x 
P(  Condition  \  lan  PositiveCondition)  x  Binding 
—>  ( Condition  — ♦  Condition) 

V  CM  :  (ran  Positive  Condition  (  WME  x  ^));  C  :  P  Condition:  b  :  Binding  • 
({CM  =  (2  A  C  =  0  ^  InstantiateConditionMatching(C ,  b)  =  0)  A 
(CM  ±  0  => 

(5  own  :  CM  • 

lnstantiateConditionMatching(CM ,  C .  b)  = 

{(firsticwn)  — *  InstantiateConditionsWME(first(second(cwn)))}^ 
InstantiateConditionMatching(CM  \  cwm.  C,  b}))  A 
(CA/ =  0  A  C  0  => 

(5  C  :  C  • 

lnstantiateConditionMatching(CM ,  C,b)  =■ 

{(c  ^  InstantiateNegativeCondition(c,  ft))}u 
Instantiate ConditiGnMatching(0f,  C  \  {c},  w))) 
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5.3.2  Instantiating  the  RHS  of  a  Match’s  Production 

MakesPic^erence  takes  a  binding  and  produces  a  function  that  translates  a  make 
into  a  preference  using  the  binding.  The  different  argument  format  allows  the 
function  to  be  easily  imaged  across  a  set.  The  binding  must  covet  all  of  the 
variables  of  an  argument  preference,  or  MakesPreference  is  undefined. 

MakesPreference  :  Binding  — ►  {Make  —  Preference) 

V  b  :  Binding  •  V  m  :  Make  • 

5  o  S  —  S  o  =  (id  Constant  0  6)  • 

((m  ^  ran  Unary M  => 

(r  up  :  Unary  Preference  \  up  =  UnaryM'^  (m)  • 
MakesPreference{b){m)  = 

I  TnakeUnaryPreference{o{up.id),  o{up . attribute) , 

oi up.  value),  up. preference)))  A 
( m  ~  ran  3inaryM  => 

(r  bp  Binary  Preference  bp  ~  BinaryM"  (m)  • 
MakesPreference{b){m)  = 

TnakeBinaryPreference{o{bp .id),  o {bp  attribute).  o{bp. value), 
bp. preference,  o{bp .referent))))) 
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5.3.3  Instantiation 

An  instantiation  contains  a  match,  a  binding  and  a  matching.  The  binding  is 
a  consistent  extension  of  the  match’s  binding  that  covers  all  of  the  variables 
of  the  production’s  right  hand  side.  The  instantiation’s  right  hand  side  is  the 
set  of  preferences  made  from  instantiating  the  production’s  makes  under  the 
instantiation’s  binding. 

The  instantiation  also  contains  a  matching.  The  matching  is  a  correspon¬ 
dence  between  all  of  the  conditions  of  the  production  and  new  conditions.  The 
new  conditions  are  instantiated  copies  of  the  production’s  conditions  under  the 
match’s  binding;  these  record  for  chunking  how  the  conditions  of  the  productions 
matched. 

_ Instantiation _ 

match  :  Match 
binding  :  Binding 

matching  :  Condition  — +  Condition 

[  Ihs  :  P  Condition 

\  rhs  :  P  Preference 

binding  Consisten  tExtension  match. binding 
dom  binding  = 

{\J{MakesComponents^match. production. rhs^)  O  Variable) 
o  dom  match,  binding 

rhs  —  {MakesPreference{binding))^match. production. rhs^ 
matching  = 

Instantiate  ConditionMatching  ( match .  matching . 

'  match  .production  .Ihs  \  tan  Positive  Condition,  match. binding) 

I 

I  Ihs  =  ran  matching 

1 _ 

mukelnstajitiation  constructs  a  new  instantiation  data  structure  schema  given 
a  match  and  a  condition  matching.  The  instantiation’s  binding,  left  hand  side 
and  tight  hand  side  are  eiil  uniquely  determined  from  the  match  and  the  condi¬ 
tion  matching. 

!  make  Instantiation  :  Match  x  ( Condition  ->-*  Condition)  —*  Instantiation 

I  V  match  :  Match:  matching  :  {Condition  ■**  Condition)  • 

binding  :  Binding-,  Ihs  :  P  Condition-,  rhs  :  P  Preference  \  Instantiation  • 
make Instantiation{match,  matching)  —  9 Instantiation 
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5.4  Goal  Operations  and  a  Match’s  Goal 

Recognition  memory  reads  the  contents  of  goal  memory  and  working  memory  to 
determine  the  support  that  instantiations  confer  on  preferences.  The  goal  stack 
is  defined  in  Chapter  7,  but  is  represented  in  working  memory  elements.  This 
section  defines  operations  that  read  from  working  memory  the  state,  operator 
and  ancestors  of  a  goal,  and  determine  the  newest  goal  that  a  match  matches 
against. 

The  state  of  a  goal  is  the  value  of  the  single  working  memory  element  of  the 
goal  that  has  attribute  state. 

I  GoalStaie  :  Identifier  x  P  TME  Identifier 

V  :  Identifier;  TM  :  P  TME  • 

j  3i  t  ;  TM  n  ran  WMETME  • 

I  3w:  WME  \  w  =  WMETME- (t)  A 

w .id  =  g  /\  w. attribute  =  '  STATE '  a 
w .  context  .^acceptable  ^preference  =  No 

•  GoalState{g,  TM)  =  w. value 

The  operator  of  a  goal  is  the  value  of  the  single  working  memory  element  of 
the  goal  that  has  attribute  operator. 

GoalOperator  :  Identifier  x  P  TME  — »  Identifier 

j  V  j  :  Identifier;  TM  :  P  TME  • 

3t:  TM  n  ran  WMETME  • 

■5  u,’  :  WME  I  w  =  WMETME-(t)  a 

w.id  =  J  A  w. attribute  =  *  OPERATOR  '  a 
w.  context -acceptable -preference  —  No 

•  GoalOperator{g ,  TM)  =  w. value 

GoalAncestors  returns  the  set  of  identifiers  of  ancestor  goals  of  a  goal. 

GoalAncestors  :  Identifier  x  P  TME  — ►  P  Identifier 

V  (^  :  Identifier;  TM  :  P  TME  • 

GoalAncestors)'  NIL TM)  —  0  A 

(3  g2  :  Identifier  ]  WMETME{TnakeWME{g, '  OBJECT  g2,  No))  c  TM  • 

G oal Ancestor s{g ,  TM)  =  {^2}  ^  GoalAncestors(g2,  TM)) 
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The  support  an  instantiation  confers  depends  upon  the  deepest  of  the  goals 
that  it  matched,  called  the  match's  goal.  Soar  constrains  its  productions  to 
match  each  root  variable  with  an  identifier  of  a  goal  or  attribute  impasse.  A 
root  variable  is  one  that  appears  only  in  the  identifier  field  of  the  production’s 
conditions. 

j  MatchGoals  :  Match  — *  P  Identifier 

MatchGoal  :  Match  x  P  TME  — *  Identifier 

I - 

V  m  :  Match  • 

MatchGoals{rn)  =  m.  binding \m.  production,  roots^j 

V  m  -.  Match  ]  TM  :  P  TME  • 

3g  :  MatchGoals{m) 

I  --  (3^2  :  MatchGoals(m)  •  gz  ^  g  ''  g  £  GoalAncestors{g2,  TM))  • 

j  MatchGoal{m,  TME)  =  g 


5.5  Chunking 

Chunking  is  Soar’s  explanation  based  learning  mechanism  [RL86i.  It  watches 
and  records  some  of  recognition  memory’s  and  decide’s  operation  into  two  trace 
memories.  When  decide  fills  a  slot  in  working  memory,  it  augments  the  work¬ 
ing  memory  trace,  TrW.  TiW  maps  each  working  memory  element  instance  to 
the  require  or  acceptable  preference  for  the  slot  and  value.  After  recognition 
memory  instantiates  a  match,  it  passes  the  instantiation  to  chunking.  Chunking 
creates  a  data  structure  called  a  trace  from  the  instantiation.  The  trace  records 
the  working  memory  element  instances  that  were  matched  in  the  form  of  instan¬ 
tiated  conditions.  The  instantiated  conditions  are  split  into  three  groups,  called 
grounds,  potentials  and  locals.  Each  preference  instance  of  the  instantiation  is 
marked  as  dependent  upon  this  trace  in  the  preference  memory  trace,  TtP. 

After  chunking  has  created  the  instantiation's  trace,  it  determines  if  the 
instantiation  augments  the  match  goal’s  parent  with  new  preferences.  If  so,  the 
results  are  used  as  a  starting  point  for  a  search  through  the  trace  memories. 
The  trace  generated  conditions  in  this  search  are  collected  and  variabilized  to 
produce  a  new  left  hand  side  for  a  production,  and  the  results  are  variabilized 
to  produce  a  new  right  hand  side. 

Chunking  is  presented  in  eleven  sections. 

•  Section  5.5.1  Extracting  Not  Tests  —  instantiations  test  values  from  their 
working  memory  elements  for  inequality.  The  resulting  chunks  must  also 
check  these  inequalities,  so  we  extract  the  not  tests  of  each  instantiation, 
store  them  in  the  traces  and  re-introduce  them  in  Section  5.5.3  Not-ify. 

•  Section  5.5.2  Variabilize  —  this  section  generalizes  the  sets  of  instantiated 
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conditions  that  chunking  finds  into  conditions  by  assigning  variables  to 
each  identifier. 

•  Section  5.5.3  Not-ify  —  re-introduces  not  tests. 

•  Section  5.5.4  Traces  —  specifies  what  is  in  a  trace  and  provides  utilities 
for  constructing  them. 

•  Section  5.5.5  Chunking’s  State  —  this  section  defines  chunking’s  state 
schema. 

•  Section  5.5.6  Changing,  InitiaUzing  and  Resetting  Chunking  —  we  define 
constraints  on  each  step  of  chunking,  as  well  as  the  standard  initialization 
and  resetting  for  chunking. 

•  Section  5.5.7  Defining  Results  —  results  are  the  preferences  that  an  in¬ 
stantiation  adds  to  its  parent  goal,  which  are  also  the  starting  point  for 
chunking’s  backtracing. 

•  Section  5.5.8  Chunking  an  Instantiation  —  this  section  provides  the  oper¬ 
ation  to  build  the  trace  for  an  instantiation,  and  to  start  the  search  back 
through  the  trace  memories. 

•  Section  5.5.9  Tracing  Seeds,  Locals  and  Grounded  Potentials  —  this  sec¬ 
tion  specifies  the  basic  tracing  operations. 

•  Section  5.5.10  Tracing  UnGrounded  Potentials  —  this  section  defines  how 
to  trace  a  special  type  of  condition  that  may  or  may  not  be  included  in 
the  chunk’s  condition. 

•  Section  5.5.11  ChunkSP  —  this  section  specifies  how  chunking  builds  the 
new  chunk  when  backtracing  has  finished. 

5.5.1  Extracting  Not  Tests 

In  this  section,  we  specify  how  to  extract  the  nots  from  a  condition.  The  nots 
are  doubletons  of  identifiers  that  the  condition  constrained  to  be  different.  The 
presentation  is  bottom  up,  starting  with  a  not  extractor  for  tests,  then  working 
memory  element  tests  and  then  condition’s  nots. 

Not  ==  {ci,  C2  :  Identifier  i  ci  ?!  cj  •  {ci,  C2}} 


70 


Most  types  of  tests  have  no  nots,  but  a  NotTest  that  matched  against  two 
identifiers  generates  a  not  doubleton. 

TestsNots  :  Binding  x  Test  x  Test  — *  P  Not 

V  h  :  Binding;  t,vt  :  Test  • 

((<  6  {BlankTest,  YesTest,  NoTest}  =>  TestsNots{b,  t,  vt)  =  0)  a 
(t  G  ran  EqualityTest  =>  TestsNots{b,  t,  vt)  =  0)  A 
(t  €  ia.li  NotTest  ^ 
j  (3  i  :  E  !  j  =  NotTest'' (t)  • 

I  ((((^  €  Variable)  A  (((id  Constant)  ©  b){s)  G  Identifier) 

A  (EgualityTest" {vt)  6  Identifier))  => 

'  TestsNots(b,  t,  ut)  =  {{((id  Constant)  Qi  6)(j).  £7uafiti/Test''(tjt)}})  a 

(((j  t  Variable)  A  (((id  Constant)  ©  6)(*)  £  Identifier) 

A  {EqualityTest'' (vt)  €  Identifier))  => 

TestsNois{b,  t,  vt)  =  0))))  A 

'  (t  €  ran  SameTypeTest  =>  TesisNots{b,  t,  vt)  =  0)  A 
(t  €  ran  Disjunctive  Test  =>  TestsNotj{b.  t,  ut)  =  0)  A 
(t  €  ran  Conjunctive  Test  => 

I  TestsNots{b,t,  vt)  = 

I  Eest  •  TestsNots{b,t,vt))l)ConjunctiveTest''{t))))) 

The  nots  of  a  working  memory  element  test  is  the  set  of  nots  in  its  id, 
attribute  and  value  tests. 

WMETestsNots  :  Binding  x  WMETest  x  WMETest  — *  P  Not 

1  V  6  :  Binding;  wt,w  :  WMETest  • 

WMETestsNots{b.  wt.w)  = 

TestsNots{b,  xut.id.  w.id)  U  TestsNots{b.  wt. attribute,  w. attribute) 
u  TestsNots{b,  uit. value,  w. value) 

We  only  extract  nots  from  positive  conditions,  as  the  nots  inside  of  a  negative 
condition  are  known  not  to  have  matched  against  any  values.  The  nots  of  a 
positive  condition  are  the  nots  of  its  working  memory  element  tests. 

I  Conditions  Nots  ;  Binding  x  Condition  x  Condition  — •  P  Not 

V  6  :  Binding;  c.  cm  :  Condition  • 

((c  G  ran  PositiveCondition  ■=s> 

CondiiionsNots{b .  c,  cm)  = 

WMETestsNots{b ,  PositiveCondition'' ( c ) , 

PositiveCondition" (cm)))  A 
(c  G  ran  PositiveCondition  => 

ConditionsN ots{b ,  c,  cm)  =  0)) 
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5.5.2  Variabilize 


Variabilize  generalizes  Chunking’s  instantiated  conditions  by  replacing  their 
identifiers  with  variables.  After  chunking  has  finished  its  search  through  the 
trace  memory,  it  picks  an  assignment,  a  partial  injection  from  identifiers  to 
variables,  that  covers  all  of  the  variables  of  its  condition.  It  recurses  down 
into  the  tests  of  its  conditions,  replacing  all  occurrences  of  identifiers  with  their 
variables. 

Assignment  ==  Identifier  «-*  Variable 

A  symbol  is  variabUized  by  returning  the  symbol  if  it  is  a  constant  and 
otherwise  by  returning  its  value  under  the  assignment. 

j  VartabilizeSymhol  :  E  x  Assignment  — ►  E 

V  c  :  E;  a  :  Assignment  • 

((c  S  Identifier 

(5  1)  :  Variable  \  v  ^  ran  a  •  VariabilizeSymbol{c ,  a)  =  r))  A 
(c  ^  Identifier  =>  VariabilizeSymbol(c,  a)  =  c)) 

A  test  is  variabUized  by  variabUizing  its  component  symbols,  or  returning 
the  test  if  it  is  indivisible. 

VanabilizeTest  :  Test  x  Assignment  — *  Test 

V  t  :  Test',  a  :  Assignment  • 

((<  €  {BlankTest,  YesTest,  NoTest]  u  ran  Disjunctive  Test 
=>  VariabilizeTest{t,  a)  =  t)  A 
{t  £  ran  EqualityTest  => 

VariabilizeTestit,  a)  = 

EqualityTest{VariabilizeSymbol(EqualityTest‘~ (t).  o)))  A 
(t  €  ran  NotTest  => 

VariabilizeTest{t,  a)  — 

NotTest{VariabilizeSymbol{NotTest'' (t),  a)))  A 
(t  €  ran  SameTypeTest  ^ 

Variabilize Test(t,  a)  = 

j  SameTypeTest{VariabilizeSymbol{SameTypeTest~' {t),  a)))  A 

(£  €  ran  Conjunctive  Test  ^ 

VanabilizeTest{t,  a)  = 

ConjunctiveTest{{(X  st  :  Test*  VanabilizeTest(st,  a)) 
j  Conjunctive  Tes£~(()0)))) 
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A  working  memory  element  test  is  variabilized  by  variabilizing  its  id.  at¬ 
tribute  and  t'alue  tests,  and  keeping  its  acceptable  preference  test. 

VanabilizeWMETeai  :  WMETesi  x  Assignment  — *  WMETest 

V  u)  :  WMETest:  a  :  Assignment  • 

j  Vanabtlize  WME Test{  w,  a)  = 

!  (/X  td  :  {  Vanabtlize  Test(w .id,  a)}  • 

(n  attribute  :  {  Vanabtlize Test{w. attribute,  a)}  • 

{fi  value  :  {  VanabilizeTest{w .value ,  a)}  • 

(^i  context-acceptable -preference  :  {w.  context -acceptable -preference}  • 
eWMETest)))) 

A  condition  is  variabilized  by  variabilizing  its  recursive  set  of  conditions  or 
its  component  working  memory  element  test. 

Vanabtlize  Condition  :  Condition  x  Assignment  — »  Condition 
VariabilizeSetOfConditiona  ; 

P  Condition  x  Assignment  — *  P  Condition 

V  c  :  Condition;  a  :  Assignment  • 

((c  €  ran  PositiveCondition 

Vanabtlize Condition{c.  a)  = 

PosttiveCondttion{  VariahiltzeWMETest(Posttiv€Condition''  [c).  a)))  ' 

(c  €  ran  NegativeCondition 
VariabtlizeCondttion(c,  a)  = 

Negative Conditton{  VanabilizeWMETest(NegativeConditton''  (c).  o)))  ‘ 

(c  €  ran  NegativeConjunctiveCondition  => 

VariabilizeConditton{c.  a)  ~ 

Negative  ConjunctiveCondttton( 

1  'artabilizeSetOfCondtttons( NegativeConjunctiveCondition "(c).  o) ) ) ) 

V  C  :  P  Condition:  a  :  Assignment  • 

((C  =  0  =>  VanabilizeSetOfConditions{C ,  a)  =  0)  a 
{C 

{3  c  :  C  • 

VanabilizeSetOfCondittons{C ,  a)  = 

{  VanabilizeConditton{c,  o)}  ^  VanabilizeSetOfConditions{C  {c}.  o)))) 
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Chunking  cannot  produce  a  set  of  instantiated  conditions  to  variabilize  be¬ 
cause  it  must  maintain  the  correspondence  between  the  conditions  and  the  work¬ 
ing  memory  element  instances  that  they  matched.  Chunking  actually  produces 
a  partial  function  from  conditions  to  working  memory  element  instances.  This 
is  variabilized  to  produce  both  a  matching  for  the  chunk’s  match  and  another 
form  for  the  chunk’s  instantiation. 

VarmbilizeConditionMatchxng  :  {Condition  {WME  x  M))  x  Assignment 

((Condition  -««  (WM£  x  ^))  x  (Condition  Condition)) 

V  mm  :  (Condition  — <  (  WME  x  f^));  a  :  Assignment  • 

((mm  —  Z  =>  VariabilizeConditionMatching(mm.  a)  =  (0.2!))  a 
(mm  ±  Z  => 

(5  c:  dom  mm  • 

I  (5  cwncc  :  {  Vanabiliz€CondittonMaiching({c}  mm.  a)}  • 

VanabilizeConditionMatchingymm,  a)  = 

({  Variabilize Conditton( c .  a)  mm(c)}  fir3t(cwncc). 

{  VariabilizeCondition(  c.  a)  — •  c}  w  second)  cwncc))))) ) 
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The  results  of  an  instantiation  are  variabiiized  to  produce  the  new  right  hand 
side  for  the  chunk.  VariabilizePreferenceToMake  maps  a  preference  to  a  make, 
and  VatiabilizeRHS  maps  a  set  of  preferences  to  its  set  of  makes. 

VartabilizePreferenceToMake  :  Preference  x  Assignment  — •  Make 

I  V  p  :  Preference;  a  :  Assignment  • 

((p  €  ran  Unary P  => 

{3  up  :  UnaryPreference  ;  up  =  UnaryP"  [p)  • 
VariabilizePreferenceToMakeip.  a)  = 

make  U nary  Make  ( VartabilizeS  ymbol  {up.  id,  a), 
VariabilizeSymbol(up •  attribute ,  a) , 

VanabilizeSymbol{up  .value ,  a),  up  .preference)))  a 
(p  c  ran  Binary P  => 

(3  bp  :  BinaryPreference  \  bp  =  BinaryP^ [p)  • 

^  VariabilizePreferenceToMakeyp ,  a)  = 

makeBtnaryMake{  VariabilizeSymbol{bp.id.  a). 

1  'ariabilizeSymbol(bp  .attribute  .a). 
VariabilizeSymbol{bp.value.  a),  bp  preference . 
VariabilizeSymboK  bp .  referent ,  a) ) ) ) ) 


VanabilizeRHS  :  P  Preference  x  Assignment  — ♦  P  Make 

V  pi  :  P  Preference;  a  :  Assignment  • 

((pi  =  2  ^  VariabilizeRHS(ps.  a)  =  0)  A 

(pi  ;£  0  => 

(5p  :  pi  • 

VanabilizeRHS {ps .  a)  = 

{  VariabilizePreferenceToMake{p.  a)}^ 
VariabilizeRHS(ps  \  {p}.  o)))) 


5.5.3  Not-ify 

When  a  trace  for  an  instantiation  is  created,  the  not  extractor  saves  the  set  of 
doubletons  of  identifiers  that  the  match’s  condition  constreiined  to  be  different. 
As  chunking  searches  through  the  memory  of  traces,  it  unions  in  the  set  of  not 
doubletons  for  each  trace  that  it  adds.  When  chunking  is  completed,  not-ify 
re-installs  these  nots  into  the  new  conditions. 
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Not-ify  is  called  after  variabilize,  so  we  map  the  set  of  doubletons  of  iden¬ 
tifiers  to  a  set  of  doubletons  of  variables,  called  VNots.  The  function  Not- 
sToVNots  maps  set  of  identifer  nots  to  variable  nots  using  the  chunk’s  assign¬ 
ment. 


VNot  ==  {«!,  uj  :  Variable  \  vi  ^  U2  •  {tii,  W2}} 


!  NotsToVNots  :  P  Not  x  Assignment  P  VNot 

!  V  IV  :  Pj  Not',  a  :  Assignment  • 

I  NotsToVNots{N ,  a)  = 

{n  :  N-,  i,j  :  Identifier  I  t  j  A  n  =  {i,j}  •  {a(i),a(j)}} 

Not-ify’s  functions  all  take  three  arguments:  an  object  to  not-ify,  the  set  of 
variable  nots  to  install  and  the  set  of  variables  bound  in  the  walk  through  the 
conditions.  As  not-ify  walks  down  the  condition  matchings,  into  the  conditions, 
working  memory  element  tests  and  tests,  it  adds  the  variables  that  the  conditions 
have  bound  to  the  set  of  variables.  As  it  descends,  it  also  installs  not  tests  for 
those  variable  nots  that  have  had  both  of  their  variables  bound.  Each  not-ify 
function  returns  the  possibly  augmented  set  of  bound  variables,  and  the  possibly 

reduced  set  of  variable  nots  left  to  be  installed. 

As  the  domains  and  ranges  of  the  not-ify  functions  must  conveniently  handle 

triples  of  items,  we  extend  the  standard  Z  first  and  second  to  sequences  of  three 
elements  ([Spi89]  93). 

^[x,  y,z]  . .  . 

i  firsts  ■  X  X  y  X  Z  —  X 
seconds  :  X  x  y  x  Z  1' 
thirds  :  A"  X  y  X  Z  Z 

V  r  :  .Y;  y  :  1';  z  :  Z  •  firsts{(x ,  y ,  z))  =  z 

^  z  :  X\  y  ■■  y  \  z  :  Z  •  seconds({x ,  y ,  z))  =  y 

'  V  I  :  A";  y  :  F;  2  :  Z  •  thirds({z,  y,  2))  =  2 


76 


NotifyTest  returns  most  tests  unmodified,  but  if  a  test  is  an  equality  for  an 
unbound  variable  it  binds  the  variable  by  adding  it  to  the  variable  set,  and  re- 
curses  to  possibly  add  in  an  as  of  yet  unassigned  variable  not.  NotifySetOfTests 
sequences  through  a  set  of  tests  in  non-deterministic  order  to  install  the  variable 
nots. 


NotifyTest  : 

Test  X  P  VNot  X  P  Variable  — * 

Test  X  P  VNoi  x  P  Variable 
NotifySetOfTests  : 

P  Test  X  P  VNot  X  P  Variable  — > 
j  P  Test  X  P  VNot  X  P  Variable 

•  V  t  :  Test;  N  :  P  VNot;  V'  ;  P  Variable  • 

((t  c  ran  Equality  Test  => 

{ E quality Te st" {t)  ^  Variable  => 

NatifyTest{t,  N ,  V)  =  (t.N.  V'))  ^ 

(Equality  Test"  {t)  c  Variable  => 

V  :  Variable  i  v  =  EquahlyTest" (t)  • 

'  ((5n:iV. 

V  ^  n  A  {n  \  {»})  n  V  ^  0)  => 

!  {3n  :  N;  V2  '■  Variable  j  n  =  {v,  vj}  A  vj  £  V  • 

'  :  {NotifyTest(Con3unctiveTest({t,  NotTest(v2)}),  N  {n}.  V)}  • 

j  NottfyTest(t,  N,  1')  =  Notify Test(first3(r),  secondalr),  ikirdslr)))))  ' 

1  ^  (3  n  :  N  •  V  ^  n  A  (n  \  {r})  V  ^  0)  ^ 

,  NotifyTest{t.N,  F)  =  {t,N,  Fu  {t>}))))  A 

j  (t  £  ran  ConjunctiveTest  => 

(3  tNV  :  {NotifySetOfTests{ConjuncixveTest" (t),  N .  1')}  • 

NotifyTest{t.  N .  F)  =  {ConjuncUveTest(first3{tNV)).  second3(tNV).  thirds { tNV)))) 
(t  £  (tan  Equality  Test  u  ran  ConjunctiveTest)  => 

NotifyTestit,  N,  V)  =  (t,  .V,  F))) 

,  V  T  P  Test;  N  ;  P  VNot:  ;  P  Fartahle  • 

!  (( T  =  0  =>  NotifySetOfTests[  T,  N,  V)  =  [T,N,  F))  A 

i  (r*0=> 

(3<:T. 

]  (3  tNV  :  {Notify Test{t,  N,  F)}  • 

I  (3  TNV  :  {Notify SetOfTests(  T  \  {(},  second3{tNV),  third3{tNV))}  • 

I  NotifySetOfTests{T,  N ,  V)  = 

({«}  U  firstsi  TNV),  secondsi  TNV),  thirdsi  TNV))))))) 


77 


NocifyWMETest  sequences  through  the  id,  attribute  and  value  to  install  the 
variable  nots. 

'  NohfyWMEresi  :  WMETesi  x  P  VNot  x  P  Variable  — 

WMETest  X  P  VNot  x  P  Variable 

V  w  :  WMETest-,  n  P  VNot,  b  P  Variable  • 

Notify  WMETest{w,  n,  b)  = 

{fj,  idnb  :  {NotifyTest(w.id,  n,  6)}  • 

{fi  attribute-nb  ;  {NotifyTest{-w  .attribute,  second3{idnb),  thirds  (idnb))}  • 

{n  attribute  :  {first3{attributenb)}  • 

(fivaluenb  :  {Notify Test{w. value,  3econd3{attribuienb),  thiTd3(attributenb))}  • 
( make  WMETest{first3(idnb),first3[attributenb), 
j  firstslvaluenb),  w.context^acceptable ^preference), 

I  second3{valuenb),  thirdslvaluenb)))))) 

NotifyCondition  unpacks  conditions  positive  conditions  to  install  variable 
nots,  but  does  not  install  nots  in  negated  conditions. 

NotifyCondition  : 

Condition  x  P  VNot  x  P  Variable  — >  Condition  x  P  VNot  x  P  Variable 

V  c  :  Condition-,  n  :  P  V'Not;  b  :  P  Variable  • 
i  ((c  €  ran  Positive  Condition  => 

j  (3  pcnb  -.  {Notify  WMETest{PositiveCondition''  [c) ,  n,  b)}  • 
j  NotifyCondition{c,n,b) — 

j  ( Positive  Condition{firsi3{pcnb)), 

second3{pcnb),third3{pcnb))))  ^ 

(c  $  ran  PositiveCondition  => 

I  Notify Condition(c,  n,  b)  =  (c,  n,  b))) 
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Finally,  NotifyConditionMatchings  recurses  through  the  two  style  of  condi¬ 
tion  matchings  to  install  all  of  the  variable  nots. 

j  Notify CanditicnMatchings  : 

!  {(Condition  (WME  x  ^))  x  (Condition  -<->  Condition))  x  P  VNot  x 
((Condition  (WME  x  M))  x  (Condition  ->-*  Condition))  x  P  VNot  x 

V  ciun  ;  (Condition  ->*  (WME  x  N));  cc  :  (Condition  ■**  Condition); 

N  :  P  VNot;  V  :  P  Vartahle  • 

((cu/n  =  0  A  cc  =  0  ^ 

NotifyConditionMatchings((cwn,  cc),  N ,  V)  =  ((0,0),  N,  F))  A 
(cuin  0  A  cc  0  :X> 

(5  c  :  dom  cwn  n  dom  cc  • 

I  (5  vcNV  :  (Notify Condition(c,  N ,  F)}  • 

I  (3  cnnccNV  :  (NotifyConditionMatchings) 

I  ({c}  cu;n,{c}  cc),  second3(vcNV),  third3(vcNV))}  • 

'  NotifyConditionMatchings  ((cwn.  ccj.  N ,  F)  = 

((first(first3(cnnccNV))  0  (first3(vcNV)  i— .  cuin(c)}, 

!  second(first3(cnnccNV))  ^  (firs1:i(vcNV)  c}), 

I  seconds (cnncclVF),  thiTd3(cnnccNV ))))))) 


5.5.4  Traces 

Chunking  builds  a  trace  for  each  instantiation  starting  with  the  set  of  instan¬ 
tiated  conditions  of  the  instantiation’s  matching.  The  trace  uses  the  contents 
of  temporary  memory  to  segregate  the  conditions  into  three  classes:  grounds, 
potentials  and  locals.  It  also  records  the  not  doubletons  that  the  match  con¬ 
strained  to  be  different  and  the  instantiation’s  matches  matching. 


P  Variable 
P  Variable 
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The  grounds  of  a  trace  are  the  instantiated  conditions  that  were  directlv 
matched  from  a  parent  goal  through  a  chain  of  conditions.  The  potentials  are 
those  conditions  that  are  in  the  transitive  closure  of  a  parent  of  the  match  goal, 
but  were  not  directly  matched  from  the  parent.  All  of  the  non-ground  negative 
conditions  ate  also  added  into  the  potentials,  as  they  can  not  be  traced  through 
because  they  never  had  a  corresponding  element  in  working  memory.  The  locals 
are  the  remaining  conditions,  and  should  be  exactly  those  positive  conditions 
that  are  available  only  from  the  transitive  closure  of  the  match  goal. 


Grounds  :  P  TME  x  Instantiation  — •  P  Condition 
Potentials  :  P  TME  x  Instantiation  — *  P  Condition 
Locals  :  ?  TME  X  Instantiation  — >  P{ia.n  PositiveCondition) 

Nots  :  Instantiation  — >  P  Not 

V  TM  :  P  TME;  1  :  Instantiation  • 

Grounds  {  TM ,  t)  = 

'^^^Conditioni 

Olid  Condition^ 

GoalAncestorsiMatchGoalii. match.  TM).  TM  ). 
ran  i. matching),  ran  i. matching) 

7  TM  :  P  TME:  i  :  Instantiation  • 

Potentials)  TM .  i)  = 

((ran  i. matching  ran  PositiveCondition)^ 

^^^Condition^ 

Condition^ 

{TCI j’j^£(TM)){GoalAncestors{MatchGoal{i. match.  TM).  TM)). 
ia.a  i. matching).  ta.ni.matching)  '  Grounds(TM .  i)) 

7  TM  :  ?  TME]  i  :  Instantiation  • 

Locals[TM.i)  =  I  a,ni.  matching  '  (Grounds  [T  M  .i)  ^  Potentials(TM  .i)) 

V  I  :  Instantiation  • 

Nots)')  =  [J{c  :  dom  i. matching  •  ConditionsNots(i. binding,  c.  i.matching(c))} 
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The  Trace  data  schema  holds  the  grounds,  potentials,  locals,  nots  and  a 
matching.  The  matching  is  a  correspondence  between  the  instantiated  versions 
of  the  positive  conditions  and  the  working  memory  element  instances  that  they 
matched. 

I _ Trace _ 

grounds ,  potentials,  locals  :  P  Condition 
nots  ;  P  Not 

matching  :  Condition  -«  (  WME  x  ) 

dom  matching  =  {grounds  u  potentials  ^  locals)  n  ran  Positive  Condition 


The  function  makeTrace  is  provided  to  simplify  the  creation  of  traces  by 
chunking. 

I  makeTrace  :  P  TME  x  Instantiation  — *  Trace 

V  TM  ;  P  TME;  t  :  Instantiation  • 
make  Trace  {  TM ,  i)  = 

{fj,  grounds  :  {Grounds{TM ,  i)}; 
potentials  :  {Potenttals{TM .  i)}; 
locals  :  {Locals{TM ,  t)}; 
i  nots  :  {7Vot5(t)}; 

matching  :  {i. match. matching}  • 

6  Trace ) 

The  components  of  a  trace  is  the  components  of  its  conditions,  nots  and  the 
components  of  the  working  memory  element  instances  that  it  matched. 

Traces  Components  :  Trace  — >  P  E 

V (  :  TVace  • 

Traces  Components  (t)  = 

[J{ConditionsComponentsl)t.grounds  O  t. potentials  U  t.localsl)u 
(J  t.notsu 

I  IJ  first  (jran  matchingl 


5.5.5  Chunking’s  State 
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Chunking's  state  machine  has  only  four  states,  but  has  the  most  complicated 
state  schema  of  any  of  Soar's  state  machines. 

•  ChunkinglnitiaJState  —  chunking  starts  in  this  state. 

•  ChunkingTraceConditionState  —  traces  through  the  loccd  conditions. 

•  ChunkingTraceUnGroundedPotentiaisState  —  traces  through  aU  of  the 
ungrounded  potentials,  one  at  a  time. 

•  ChunkingFinishedState  —  chunking  finishes  in  this  state. 


ChunkmgState  Chunking ImtialState 

Chunking  Trace CondiiionStaie 
\  Chunking  TraceUnGroundedPoientialsState 
ChunkingFinishedState 

When  chunking  processes  an  instantiation,  it  may  or  may  not  produce  a 
chunk,  depending  upon  the  results  of  the  instantiation's  right  hand  side.  If  it 
does  produce  a  new  chunk,  then  it  returns  the  new  instantiation  for  that  chunk 
so  that  preference  phase  can  process  it.  The  ChunkingResult  type  is  used  to 
inform  the  preference  phase  that  chunking  is  returning  a  new  instantiation. 

ChunkingResult  Newinstantiation  Nolnstantiation 

Soar  is  actually  viewed  as  continuously  learning  from  its  operation.  How¬ 
ever,  in  practice  Soar's  learning  mechanism  is  the  most  difficult  part  of  Soar 
to  use.  Chunking  is  difficult  to  use  for  a  variety  of  reasons;  it  is  rather  com¬ 
plicated  so  users  find  it  difficult  to  understand,  it  can  create  expensive  rules 
which  prohibitively  degrade  performance  ([Tam91j),  it  has  some  knowm  over¬ 
generalization  problems  (TCAS90],  70,  73,  74).  and  it  has  yet  to  be  weU  inte¬ 
grated  with  our  theoretical  framework  -  the  problem  space  computational  model 
(iNYL^9lj). 

For  convenience  we  allow  Soar  users  to  turn  learning  partially  off  in  two 
ways.  The  chunking  state  schema  has  a  switch  learn  of  type  Learn.  When  learn 
is  off  or  if  chunking  backtraces  through  a  local  goal’s  *  QUIESCENCE  '  element, 
a  chunk  is  learned  but  it  is  not  variabilized  and  not-ified.  These  internal  chunks 
act  like  restricted  productions;  they  can  match  only  one  sequence  of  elements, 
they  confer  support  on  their  resulting  preferences,  and  they  are  guaranteed  to 
be  very  cheap  to  match.  When  an  internal  chunk's  single  instantiation  retracts. 
Soar  deletes  the  production  from  production  memory  as  it  is  never  likely  to 
match  again. 

Learn  ::=  On  Off 

Chunking  shares  six  memories  with  other  modules: 
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•  SPM  —  the  set  of  productions 

•  TM  —  temporary  memory 

•  WM  —  working  memory 

•  PM  —  preference  memory 

•  GM  —  goal  memory  and 

•  IS  —  instantif^tion  memory,  the  set  of  matches  that  have  been  instantiated 
by  the  preference  phase. 

_ Chunking _ 

SPM  :  P  SP 
TM  :  P  TME 
WM  :  P  WME 
PM  :  P  Preference 
GM  :  P  Identifier 
IS  :  P  Instantiation 
:  WM#  :  WME  1^ 
i  PM  if  :  Preference  ►*+ 

I  max -preference ,  max-wme  :  ^ 

TrP  :  {Preference  x  N)  x  Identifier  -«  Trace 
,  TrW  :  {WME  X  M)  X  Identifier  {Preference  x  f^) 

I  learn  :  Learn 

instantiation  :  Instantiation 
I  goal  :  Identifier 
results  :  P  Preference 
seeds  :  P  Preference 

grounds ,  potentials,  ungrounded -potentials  :  P  Condition 
locals  :  P  {ran  Positive  Condition) 

I  nots  :  P  Not 

1  matching  :  Condition  ->-»  {WME  x  1^) 

!  chunking -State  :  ChunkingState 
I  chunking-result  :  ChunkingResult 

i  goal  E  CM 

I  dom  WM#  =  WM 

dom  PM  #  =  PM 

{first  i  second){TrP^  C  GM 

{first  i  second){TrW^  C  GM 


Chunking  introduces  four  new  memories  of  indefinite  extent. 
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•  TiP  —  the  trace  memory  for  preferences. 

•  TtW —  the  trace  memory  for  working  memory  elements. 

•  WM  #  —  a  numbering  function  that  distinguishes  the  instances  of  each 
working  memory  element  in  memory. 

•  PM  #  —  a  numbering  function  that  distinguishes  the  instances  of  each 
preference  in  memory. 

WM  #  and  PM  #  are  partial  injections  that  provide  a  way  for  chunking 
to  distinguish  between  two  different  elements  that  were  in  memory  at  differ¬ 
ent  times.  The  numberings  were  defined  in  this  section  because  only  chunking 
must  actually  distinguish  between  the  instances  of  memory  elements.  As  prefer¬ 
ence  phase  generates  new  preferences,  and  decide  and  10  generate  new  working 
memory  elements  they  extend  the  numbering  to  give  each  new  element  a  new 
number.  We  chose  this  numbering  function  representation  instead  of  giving 
each  working  memory  element  and  preference  a  number  component  because  it 
allowed  us  to  still  use  the  standard  set  theoretic  operations,  instead  of  having 
to  define  our  own  little  set  theory  for  just  sets  of  WMEs  and  Preferences. 

TrP  records  for  each  preference.  >n  each  goal,  the  trace  that  generated  that 
preference  instance.  Similarly,  TrW  records  for  each  working  memory  element 
instance,  in  each  goal,  the  acceptable  or  require  preference  instance  that  was 
in  memory  when  decide  added  the  working  memory  element  instance.  The 
invariants  on  the  chunking  schema  require  that  the  traces  are  only  for  current 
goals.  The  specification  would  be  more  accurate  if  the  trace  memories  were 
explicitly  contracted  when  goals  are  popped,  but  this  simpler  data  invariant 
describes  the  intent  without  making  the  impasser's  already  large  operations 
larger. 

Chunking  holds  a  dozen  other  pieces  of  state  for  use  during  its  state  ma¬ 
chine’s  execution. 

•  instantiation  —  the  instantiation  that  preference  phase  has  passed  to 
chunking. 

•  goal  —  the  match  goal  of  the  instantiation. 

•  results  —  the  results  of  the  instantiation. 

•  seeds  —  the  seeds,  starts  out  as  the  set  of  results  but  is  deleted  as  each 
result  backtraced. 

•  grounds,  potentials,  locals  —  the  grounds,  potentials  and  locals  set  of 
chunking's  search  through  the  trace  memories. 

•  nots  —  the  nots  of  chunking’s  search. 
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matching  —  the  matching  that  maps  chunking's  conditions  (grounds,  po¬ 
tentials  and  locals)  to  the  working  memory  instances  they  matched. 

chunking_state  —  the  state  counter. 


•  chunking_result  —  a  flag  that  informs  the  preference  phase  if  it  is  receiving 
a  new  instantiation  back  that  it  should  calculate  support  from. 

•  ungrounded-potentials  —  the  set  of  ungrounded  potentials  that  chunking 
must  backtrace  one  step. 

5.5.6  Changing,  Initializing  and  Resetting  Chunking 

When  chunking  runs,  it  does  not  modify  the  contents  of  temporary  memory.  If 
it  changed  temporary  memory  then  the  calculations  for  the  traces  of  instantia¬ 
tion  from  the  same  parallel  preference  phase  would  have  ordering  dependencies. 
We  define  A  Chunking  to  emphasize  that  chunking  does  not  modify  temporary 
memory  and  that  it  adds  to  the  contents  of  production  memory. 

, _ A  Chunking _ 

Chunking 

Chunking' 

'  TM'  =  TM 

SPM  C  SPM' 
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InJtChunkJng  specifies  legal  initial  states  for  chunking. 

_ InitChunking _ 

I  Chunking 

TtP  =  0 

TrW  =  0 

resTiits  =  0 

seeds  =  0 

grounds  =  potentials  =  0 
I  locals  =  0 
I  notj  =  0 
I  matching  =  0 

chunking  ^state  =  ChunkingFinishedState 
j  max  ^preference  =  0 
I  maz_ujme  =  0 

Chunkinginiciahze  initializes  chunking  by  placing  it  in  the  initial  state. 

_ _ Chunkinglnitialize _ 

I  A  Chunking 

I  chunking  ^state  =  ChunkingFinishedState 
results  =  0 
i  seeds  =  0 

j  grounds  =  potentials  =  0 
locois  =  0 
nets  =  0 
matching  =  0 

chunking  ^state'  =  ChunkinglnitialState 
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When  chunking  is  externally  reset,  it  must  have  all  of  its  memories  for  the 
current  search  through  trace  memory  emptied. 

_ ChunkingReset _ 

A  Chunking 

chunking  ^state'  =  Chunking  FinishedState 
results  =  0 
j  seeds  =  0 

grounds  =  potentials  =  0 
locals  =  0 
I  nots  =  0 
!  matching  =  0 


5.5.7  Defining  Results 

When  an  instantiation  modifies  the  transitive  closure  of  a  goal,  it  is  said  to  add 
results  to  that  gotd.  The  results  are  the  preferences  that  the  instantiation  would 
make  available  when  its  right  hand  side’s  preferences  are  added  in  isolation  to 
preference  memory.  These  result  preferences  are  used  as  the  starting  point,  or 
seeds,  of  chunking’s  search  through  trace  memory. 

I  Results  :  Identifier  x  Instantiation  x  P  TME  P  Preference 

V  g  :  Identifier:  i  :  Instantiation:  TM  :  P  TME  • 

5  TMplusRHS  :  P  TME  TMplusRHS  -  TM  ^  PreferenceTME\i.rhsl  • 
Results{g.  i.  TM)  = 

PreferenceTME- TMplusRffS)){{g}).  TMplusRHS) 
\(Ondji^£(TCJ'j'j^f£(  TM)({^}),  TM)))  ran  Preference  TM  El 

5.5.8  Chunking  an  Instantiation 

Chunking  does  one  of  three  things  with  each  instantiation:  starts  tracing  it, 
skips  it  because  it  is  in  the  top  goal,  or  skips  it  because  it  generates  no  results. 
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If  the  instantiation  heis  results.  ChunkingStartTracing  makes  a  trace  for 
it.  and  inititilizes  the  search  through  the  backtrace  memories  from  the  trace’s 
components. 

_ Chunking  Start  Tracing _ 

A  Chunking 

chunking  ^siate  =  ChunkinglnitialState 

!  goal'  =  MatchGoal{instantiation.match,  TM) 

TrP'  =  TrPe 
{p  :  instantiation.rhs  • 

{{p .  PM goal)  — «  makeTracel  TM .  instantiation)} 

3g  :  CM 

1  maJfeeW^M£:(^oal', 'OBJECT',^,  Afo)  €  WM  A 

Results{g,  instantiation.  TM)  -x  0  • 

{results'  —  Results(g ,  instantiation.  TM)  A 
seeds'  =  results') 

grounds'  =  Grounds{TM ,  instantiation) 

potentials'  =  Potentials)  TM ,  instantiation) 

locals'  =  Locals)  TM.  instantiation) 

nots'  =  Nats  {instantiation) 

matching'  =  instantiation.match.matching 

chunking  ^state'  —  ChunkingTraceConditionState 


If  the  match  goal  of  the  chunk  is  the  top  goal,  then  it  can  not  give  any  results 
to  a  parent  goal.  This  makes  it  uninteresting  to  the  chunker,  so  it  does  not  need 
to  store  a  trace.  Chunking  finishes  and  sets  the  results  flag  to  teU  preference 
phase  that  no  new  instantiation  was  generated. 

_ Chunking  Ignore  InstantiationInT op  Goal _ 

A  Chunking 

chunking  _state  =  ChunkinglnitialState 
~{lg  :  GM  • 

makeWMEi MatchGoal{instantiation  match.  TM). '  OBJECT  '.  g.  No) 
q  WM  ) 

chunking^result'  =  No  Instantiation 
chunking  state'  =  ChunkingFinishedState 
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If  the  trace  has  no  results,  then  chunking  builds  the  trace  for  its  preferences 
and  returns  to  preference  phase. 

_ ChunkingNoResults _ 

A  Chunking 

chunking  dilate  =  ChunkingInitialState 

3g-.  GM  \  makeWME(go<d,' Om-ECT’ ,g,  No)  e  WM  • 

Resulti{g,  instantiation,  TM)  —  (d 

I  TrP'  =  TVP® 

{p  :  instantiation.rhs  • 

;  {(p,  PMi^(p)),  goal)  ^  makeTrace{TM ,  instantiation)} 

1 

chunking  ^result'  =  No  Instantiation 
I  chunking  ^state'  =  ChunkingFinishedState 


When  Decide  fills  out  slots  in  working  memory,  it  must  augment  the  TrW. 
It  gives  each  element  a  trace  that  maps  it,  under  the  oldest  goal  that  it  is  in  the 
transitive  closure  of,  to  the  require  or  acceptable  preference  instance  for  it  in 
preference  memory.  The  Owner  function  finds  the  oldest  goal  that  an  identifier 
is  in. 


I  Owner  :  Identifier  x  P  Identifier  x  P  TME  Identifier 

\  V  t  ;  Identifier  ;  GM  :  P  Identifier;  TM  :  P  TME  • 

3g:  GM  lie  TCM(g,  TM)  A 

(5  one  :  GoalAncestors{g ,  TM)  •  i  €  TCM(anc,  TM)  • 
Owner{i,  GM ,  TM)  —  g 

TtaceWME  provides  an  operation  for  decide  and  io  to  use  to  augment  the 
working  memory  instance  number  and  trace.  As  preference  semantics  processes 
requires  before  acceptables,  TraceWME  favors  requires  over  acceptable  prefer¬ 
ences. 
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^  Trace  WME _ 

A  Chunking 
u  ;  WME 

I  !  1 

j  max-wme  =  max^wme  +  1 

WMi^'  =  WMi^  0  {«)  ►-*  max-wme'} 

3p  :  PM  \ 

p  =  make Unaj^Preference{first{w?). id,  first{w?). attribute,  first{w?). value, ' • 
TrW'  =  Trw  0  {((ti),  WM #'(«>)),  Owner{w.id))  ^  (p,  PM#(p))} 

(3  p  :  PM  • 

p  =  make  Unary  P  reference  {w  .id,  w. attribute,  w. value,  ' ! ')) 

A 

I  3p: PM  I 

p  =  makeUnaryPreference{w.%d,  w. attribute,  w. value,  ‘  • 

TrW  =  Trw  0  Owner{w.id))  ^  (p,  PM#(p))} 


Traceltems  adds  new  traces  for  the  items  augmentation  of  impasses.  The 
items  augmentations  are  traced  back  to  the  require  or  acceptable  preference 
that  caused  them  to  be  considered  for  their  slot. 

_ Traceltems _ 

A  Chunking 

I  W  :?  WME 

t  :  Identifier 

! - 

!  max-wme'  =  max-wme  ~  if  W 

zf.W>-*  [max-wme  1  . .  max...wme')  •  WMH'  —  WMH  ©  f 

I  __ 

3  object,  attribute  :  Identifier 

makeWME{i,'  OBJECT  ',  object)  €  WM  A 
j  maikeH'^M.F(x, '  ATTRIBUTE oftri6ute)  €  WM  • 

TrW'  =  Trw® 

{u;  ;  W;  p  :  PM  |  p  =  make  Unary  Preference  [object,  attribute,  w. value, 

{{w,  WM#'(u>)),  Owner (t«.»d))  (p,  PM#(p))}0 

{ui  :  W ,  p  :  PM  \  p  =  makeUnaryPreference[object,  attribute,  w. value,  !  ’)  • 
((tu,  WMif'(w)),  Owner(w.id))  — •  (p,PM#(p))} 


5.5.9  Tracing  Seeds,  Locals  and  Grounded  Potentials 

The  ChunkingTraceConditionState  performs  most  of  the  seaich  through  trace 
memory.  Its  one  composite  operation,  ChunkingTiaceCondition,  traces  through 
local  conditions  in  one  of  seven  ways. 
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•  ChunkingTraceSeed  —  if  a  seed  has  a  preference  trace  for  the  goal,  then 
follow  it. 

•  ChunkingSkipSeed  —  if  a  seed  does  not  have  a  preference  trace  for  the 
goal,  then  skip  it. 

•  ChunkingTraceLocal  —  if  a  local’s  working  memory  element  has  a  trace, 
then  foUow  it. 

•  ChunkingSkipArchitectureGeneratedLocaJ  —  if  a  loc.al  matched  an  archi¬ 
tecturally  generated  working  memory  element,  skip  it. 

•  ChunkingTraceQuiescenceLocal  —  if  a  local  matched  the  goal’s  quiescence 
working  memory  element  then  add  a  quiescence  condition  to  the  grounds 
set. 

•  ChunkingPotentializeLocal  —  if  a  local  condition’s  working  memory  ele¬ 
ment  does  not  have  a  working  memory  element  trace  for  this  goal,  then 
move  it  to  the  potential’s  set. 

•  ChunkingTraceGtoundedPotential  —  if  there  are  no  more  locals,  and  a 
potential’s  condition  is  in  the  transitive  closure  of  the  grounds  set,  then 
move  it  to  the  grounds. 

The  seed  preferences  are  the  starting  point  for  chunking’s  search  through 
trace  memory.  The  seeds  are  processed  first,  and  then  the  locals  and  finally 
the  potentials.  If  a  seed  has  a  preference  memory  trace,  chunking  follows  it  by 
removing  the  seed  from  the  seed  set.  and  unioning  the  trace’s  components  into 
it’s  search  memories. 

_ ChunkingTraceSeed _ 

A  Chunking 

chunking  ^state  =  ChunkingTraceConditionState  —  chunking  ^siate' 

!  3  »  :  seeds  • 

3t  :  Trace  \  t  =  TrP((s,  PM#(s)),  goal)  • 

((seeds'  =  seeds  \  {j})  A 
(grounds'  —  grounds  U  t. grounds)  A 
(potentials'  =  potentials  O  t. potentials)  A 
!  (locals'  =  locals  U  t. locals)  A 

i  (nots'  =  nots  U  t.nots)  A 

!  (matching’  =  matching  0  t. matching)) 
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Chunking  skips  seeds  that  do  not  have  a  preference  trace  in  the  match  goal. 
They  were  g-svietated  in  the  parent  goal  and  are  in  the  transitive  closure  of  the 
results  without  being  part  of  the  results. 

I _ ChvnkingSkipSeed  _ _ _ _ 

A  Chunking 

I  chunkinn  _state  —  ChunkingTraceConditionStaie  =  chunking— state' 

3s:  seeds  j 

I  -<  (3t  :  Trace  j  t  =  TrP{(s,  PM#(i)),  goal))  • 

{{seeds'  =  seeds  \  {j}) 

{grounds'  =  grounds)  A 
{potentials'  =  potentials)  A 
j  {locals'  =  locals)  A 

!  {nois'  =  nots)  A 

{matching'  =  matching)) 


Chunking’s  basic  step  in  the  search  is  to  backtrace  through  a  local.  The 
local  condition’s  matched  working  memory  element  is  chrised  through  the  work¬ 
ing  memory  trace,  and  the  resulting  preference  instance  is  chased  through  the 
preference  trace  to  arrive  at  a  trace.  This  trace’s  components  are  unioned  into 
the  search  memories,  and  the  local  is  discarded. 

_ ChunkingTraceLocal _ 

A  Chunking 

chunking -State  =  ChunkingTraceConditionState  =  chunking  state’ 

seeds  —  <Z 

3  I  :  locals  • 

3  t  :  Trace  I 

(  =  Tr P{TrW {matching 'yl),  gc  goat)  • 

{{grounds'  =  grounds  U  t. grounds)  A 
{potentials'  =  potentials  U  t. potentials)  A 
{locals'  =  {locals  U  t. locals)  \  {!})  A 
{nots'  =  nots  U  t.nots)  A 

{matching'  =  ({/}  matching)  0  t. matching)) 
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When  decide  constructs  a  goal  or  an  impasse  it  represents  it  as  elements 
in  working  memory.  ImpasseAttiibute  is  the  set  of  the  attributes  it  uses  to 
represent  goals  and  imptisses. 

I  Impasse  Attribute  :  P  Constant 
Impasse  Attribute  — 

{'  PROBLEM-SPACE  * ,  ‘  STATE ' ,  *  OPERATOR " ,  ‘  OBJECT ' , 

“  ATTRIBUTE '  IMPASSE  '  CHOICES  *  ITEM  *  QUIESCENCE  ' 
'TYPE'} 

All  but  the  items  working  memory  elements  of  these  goals  have  no  working 
memory  traces.  Decide  adds  working  memory  traces  that  make  the  items  depend 
upon  the  preference  instance  for  the  require  or  acceptable  preference  that  caused 
decide  to  generate  the  impasse. 

_ ChunkingSkipArchitectureGeneratedLocal _ 

A  Chunking 

I  chunking  ^state  =  ChunkingTraceConditionState  =  chunking  _  state' 

\  seeds  =  0 

3  I  :  locals;  w  :  WME 

w  =  first{matching{l))  A 
w.td  €  CM  A 

w. attribute  €  ImpasseAttribute  \  {'  ITEM  '}  A 
I  w .context ^acceptable ^preference  =  No  • 

I  {{grounds'  =  grounds)  A 
{potentials'  =  potentials)  a 
{locals'  =  locals  '  {!})  A 
(riots'  =;  nots)  A 
{matching'  =  {/}  .^  matching)) 
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The  'QUIESCENCE'  goal  working  memory  element  is  used  to  turn  off 
chunking  for  a  goal  that  the  user  does  not  want  to  chunk.  When  the  user 
knows  that  the  processing  in  a  subgoal  will  generate  a  problem,  she  simply 
makes  one  or  more  of  the  productions  that  fire  in  the  subgoal  match  the  goal’s 
quiescence  working  memory  element.  When  chunking  backtraces  through  this 
quiescence  element,  ChunkingTra.ceQuiescenceLocaI  traces  it  back  to  the  quies¬ 
cence  element  of  the  parent  goal.  When  chunking  has  finished,  the  presence  of 
the  quiescence  augmentation  in  the  grounds  set  tells  chunking  not  to  variabilize 
the  rew  chunk. 

_ _ ChunkingTraceQuiescenceLocal _ 

A  Chunking 

chunking  ^state  =  ChunkingTraceConditionState  =  chunking  ^state' 

I  seeds  =  0 

!  r  1  :  locals-,  w  :  WME:  g  :  GM  \ 
w  =  first{matching(l)) /\ 

[  w.id  £  GM  A 

j  w. attribute  =  'QUIESCENCE'  A 

I  w .  value  =  '  T  '  A 

!  w .context ^acceptable ^preference  =  No  a 

i  maJbe  WME{goal, '  OBJECT ' ,  g,  No)  6  WM  • 

d  qc  : 

{  Positive  Condition( 

makeWMETest(EgualityTest(g), 
i  Equality  Test  CQUIESCEJ^CE'), 

EqualityTest('  T "),  NoTest))}  • 

3  qw  :  WME  ! 

qw.id  =  3  A  qw. attribute  =  'QUIESCENCE'  a 
qw. value  ==  '  T  '  A  qw  .context  ^acceptable  ^preference  =  No  • 
{{grounds'  =  grounds  U  {9c})  A 
!  {potentials'  =  potentials)  A 

j  {locals'  =  locals  \  {!})  A 

i  (nets'  =  nots)  A 

j  {matching'  =  {{1}  matching)  0  {9c  — »  {qw,  WMfi{qw))})) 
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When  chunking  traces  back  to  a  local  that  does  not  have  an  trace  record 
for  the  current  goal,  chunking  makes  the  local  a  potential.  A  working  memory 
element  that  was  accessible  locally  in  a  match  but  does  not  have  trace  for  that 
goal,  has  to  have  been  brought  down  from  a  parent  goal.  For  this  local  to  be 
accessible  in  the  current  goal,  but  not  to  have  a  trace  record  for  the  goal,  it 
must  have  been  brought  down  as  part  of  the  transitive  closure  of  an  element 
from  a  parent  goal,  which  later  had  its  parent  goal  link  snapped.  So  chunking 
adds  it  to  the  set  of  potentials  as  there  will  be  a  chain  of  conditions  through 
trace  memory  that  will  eventually  ground  out  this  local. 

_ Chunking?  otentializeLocal _ 

A  Chunking 

!  chunking  ^siate  =  ChunkingTraceConditionStaie  =  chunking  ^state' 

I 

j  seeds  =  0 
3  I  :  locals  \ 

I  ^  (3t  :  Trace  •  t  —  TrP{TrW (maiching{l),  goal),  goal))  • 

I  ({grounds'  —  grounds)  A 

I  (potentials'  =  potentials  U  {1})  A 

(locals'  —  locals  \  {!})  A 
[  (nets'  =  nots)  A 

I  (matching'  =  {/}  matching)) 


When  there  are  no  more  seeds  and  locals  to  process,  chunking  adds  the 
potentials  that  are  connected  to  the  grounds  into  the  grounds  set. 

_ Chunking  Trace  GroundedFotential _ 

A  Chunking 

I  chunking  state  =  ChunkingTraceConditionState  =  chunking  _  state' 
j  seeds  =  0 
locals  =  0 
3  gp  '■  potentials  \ 

gp  G  jj(jgjj(gTounds ,  grounds  U  potentials)  O  potentials  • 

((grounds'  =  grounds  U  {?P})  ^ 

I  (potentials'  =  potentials  \  {ffp})  a 
j  (locals'  =  0)  A 

I  (nots'  =  nots)  A 

i  (matching'  =  {gp}  <  matching)) 
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CbunkingTraceCondition  is  a  composite  operation  that  groups  the  tracing 
for  locals  and  grounded  potentials. 

Chunking  Trace  Condition  = 

Chunking  TraceSeed  V  ChunkingSkipSeed  v 

ChunkingTraceLocal  v  ChunkingSkipArchitectureGeneratedLocal  V 
ChunkingTraceQuiescenceLocal  V  Chunking PotentializeLocal  V 
Chunking  Trace  G rounded? otential 


5.5.10  Tracing  UnGrounded  Potentials 

Chunking  is  not  able  to  connect  all  of  the  potential  conditions  into  the  grounds 
set.  When  the  seeds  and  locals  ate  empty,  and  no  potentials  that  are  connected 
to  the  grounds  set  remains.  ChunkingStaitTiaceUnGTOundedPotentiaJs  moves 
chunking  into  the  trace  ungrounded  potentials  state.  This  state  backtraces  one 
step  through  all  of  the  positive  potentials.  It  saves  all  of  the  entering  potentials 
in  the  ungrounded^poten tiaJs  set.  so  that  it  can  augment  the  potentials  set  with 
the  potentials  of  newly  backtraced  traces. 


r 


ChunkingStartTrace  UnGroundedPoientials _ : _ 

A  Chunking 

chunking  ^state  =  ChunkingTraceConditionState 
seeds  —  0 
locals  =  0 

~  -  gp  :  potentials  • 

gp  €  TClQg^ji^-^^(grounds,  grounds  O  potentials)  r  potentials) 
potentials'  =  0 

ungrounded -potentials'  =  potentials 

chunking -State'  =  ChunkingTraceUnGroundedPotentialsState 


97 


Each  positive  potential  with  a  trace  is  backtraced  in  the  standard  way. 


^ _ ChunkingTraceUnGroundedPotential _ 

[  A  Chunking 

chunking  ^state  =  ChunkingTraceUnGroundedPotentialsState  =  chunking  _siate 

d  gp  :  ungrounded  ^potentials  O  (ran  PositiveCondition)  • 

3t  :  Trace  \  t  =  TrP{TrW [matching (gp),  goal),  goal)  • 

'  [{grounds'  =  grounds  U  t. grounds)  A 

[ungrounded -potentials'  =  ungrounded -potentials  \  {^p}) 

[potentials'  =  Ut. potentials)  A 
[locals'  =  locals  t. locals)  A 
[nots'  —  nots  w'  t.nots)  A 
[matching'  =  {gp}  matching)) 


Chunking  skips  positive  potentials  that  don’t  have  a  trace. 

_ ChunkingSkipUnGroundedPotential _ 

A  Chunking 

j  chunking -State  =  ChunkingTraceUnGroundedPotentiaisStaie  —  chunking  state 

3  gp  :  ungrounded -potentials  n  [mn  PositiveCondition) 

(3  <  :  Trace  •  t  =  TrP[TrW [matching) gp),  goal),  goal))  • 

[(grounds'  =  grounds)  A 

[ungrounded-potentials'  =  ungrounded-potentials  \  {gp}) 

[potentials'  =  potentials)  A 
[locals'  =  locals)  .A 
[nots'  —  nots)  A 
[matching'  =  matching)) 
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When  all  of  the  positive  potentials  have  been  traced,  chunking  returns  to  the 
trace  condition  state  to  backtrace  the  newly  generated  locals.  The  potentials 
collected  while  backtracing  the  positive  ungrounded  potentials  are  unioned  with 
the  remaining  negated  ungroundable  potentials. 

_ ChunkingTraceUnGroundedPotentialsDone _ 

I  A  Chunking 

!  chunking  ^state  =  ChunkingTraceUnGroundedPotentiahState 

ungrounded  ^potentials  \ 

{p  :  ungrounded -potentials 

-'(3t:  Trace  •  t  =  TrP{TrW(matching{p),  goal),  goal))}^ 

(ran  PositiveCondition)  =  (Z3 

potentials'  =  potentials  U  ungrounded -potentials 

ungrounded -potentials'  —  (Z 

chunking -State'  —  Chunking  Trace  Conditions  tate 


5.5.11  ChunkSP 

When  the  seeds,  the  locals  and  all  of  the  positive  potentials  and  the  groundable 
negative  potentials  have  been  traced,  backtracing  is  done  and  chunking  gen¬ 
erates  the  new  production.  If  learning  is  on  and  the  grounds  do  not  match  a 
quiescence  test,  then  chunking  variabilizes  the  grounds  and  results  to  builds  the 
new  production.  Chunking  also  constructs  the  match  that  the  matcher  would 
generate,  and  uses  this  in  constructing  an  instantiation  for  the  new  chunk,  which 
it  adds  to  the  instantiation  set.  The  new  instantiation  is  handed  back  to  the 
preference  phase.  Preference  phase  Ccdculates  the  new  instantiation’s  support, 
and  then  sends  it  back  into  chunking  to  have  its  results  chunked  up  the  hierarchy 
of  goals. 


_ ChunkingFinishLearnOn _ 

A  Chunking 

chunking  ^state  =  CkunkmgTraceCondiiionState 
seeds  =  0 
I  locals  —  0 

potentials  n  ran  Positive  Condition  =  0 
j  learn  =  On 

i  (3  9C  :  PositiveCondition'~  ^grounds  n  ran  Positive  Condition  |  • 
i  Equality  Test"  (qc. id]  €  CM  A 

I  Equality  Test"  (qc.  attribute)  A=  'QUIESCENCE'  A 

EqualityTest" (qc.value)  =  '  T ') 

(grounds,  grounds  U  potentials)  ^  potentials  =  0 

;  3a:  Assignment',  name  :  Symbol  • 

;  3  negativeconditions  :  {  VariabilizeSetOfConditions{grounds  \  ran  PositiveCondition,  o)}  • 

I  3  cwcc  :  {Notify ConditionMatchings{ 
i  VariabilizeConditionMatching{grounds  <  matching,  a), 

NotsToVNots(nots,  tt),0)}  • 

3  match  ^matching  :  {first(first3{c'wcc))}  • 

3  instantiation  ^matching  :  {second(first3{cwcc))}  • 

3  sp  :  SP  j  sp  =  makeSP [name ,  negativeconditions  U  dom  match-matching , 

I  V'ariabilizeRHS(result3 .  a))  • 

I  3m:  Match  i  m  =  makeMatch{sp.  match-matching)  • 

j  3  i  :  Instantiation  \  i  =  makeJnstantiation{m.  instantiation— matching)  • 

1  {SPM' =  SPM  u  {sp}  ^ 

i  /5'  =  /5u{i}) 

I  chunking -result  =  N  e'w  Instantiation 

I 

chunking -State'  =  ChunkingFinishedState 


100 


If  learning  is  off  or  quiescence  is  matched,  chunking  creates  the  new  match 
and  instantiation  without  variabilizing  it  and  returns  the  instantiation  to  pref¬ 
erence  phase. 

_ ChunkingFimshLearnOff _ 

A  Chunking 

chunking  ^state  =  ChunkingTraceConditionState 
leant  =  Off  v 

(B  qc  :  PositiveCondition"  ([grounds  n  ran  Positive  Condition}  • 

I  Equality Test~ {qc. id)  €  GM  A 
I  p9uaiityTest'“(9C. attribute)  A=  *  QUIESCENCE  '  A 
I  Equali'vTest’'  (qc. value)  =  'T') 

I  ^  m  ;  Match  I  m  =  makeMatch(sp,  grounds  <  matching)  • 

!  5i  :  Instantiation  \  i  =  makeInstantiation(m,instantiation-matching)  • 

'  (SPM'  =  SPM  ^{sp)  ^ 

/5'  =  /5o{i}) 

chunking  ^state'  =  Chunking  FinishedState 


5.5.12  Step  Chunking 

ChunkingStep  groups  all  of  the  operations  of  chunking  together  into  one  oper¬ 
ation  that  drives  the  entire  state  machine. 

ChunkingStep  = 

ChunkingStart Tracing  v  ChunkinglgnorelnstantiationlnTopGoal  \ 
ChunkingNoResults  v  CkunkingTraceCondition  v 
ChunkingStart  Trace  UnGroundedPotentials  V 

ChunkingTraceUnGroundedPotential  V  ChunkingSkipUnGroundedPotential  v 
ChunkingTrace  UnGroundedPotentialsDone  V 
ChunkingFinishLearnOn  V  ChunkingFimshLearnOff 


5.6  Slots 

The  modules  of  Soar  all  view  preference  and  working  memory,  as  being  par¬ 
titioned  into  sets  of  preferences  for  individual  slots.  Each  slot  is  an  identifier, 
symbol  pair. 

Slot  =—  Identifier  x  Symbol 
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The  preferences  for  a  slot  are  those  that  hold  the  identifier  of  the  slot  in 
their  id  component,  and  the  symbol  of  the  slot  in  their  attribute  component. 

Similarly,  it  views  working  memory  as  partitioned  into  sets  of  working  mem¬ 
ory  elements  for  slots.  The  slot’s  working  memory  elements  are  those  that  hold 
the  slot’s  identifier  in  their  id  component,  and  the  symbol  in  their  attribute, 
and  are  not  context  acceptable  preferences. 

;  Slots  WMEa  :  Slot  x  P  WME  ->  P  WME 

V  slot  ■.  Slot-  WM  P  WME  • 

Slots  WMEs{slot,  WM)  = 

{w  :  WM  )  w.id  —  first(slot)  A 
w. attribute  =  second(slot)  A 
w.  context  ^acceptable -preference  =  No} 


5.7  Recognition  Memory’s  State 

Recognition  memory’s  state  schema  contains  a  slate  counter  for  preference  phase 
and  12  memories,  some  of  which  are  shared  with  other  modules  and  some  of 
which  are  local  to  recognition  memory. 
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The  preference  phase  has  seven  states. 

1.  PPhaselniti&lState  —  the  preference  phase  starts  execution  from  here. 

2.  PPhaseRetractlnstajitiationState  —  this  state  removes  the  instantiations 
from  the  instantiation  set  which  no  longer  have  a  match  that  is  consistent 
with  working  memory. 

3.  PPhaselnstantiateMatchState  —  this  state  instantiates  matches  that  do 
not  yet  have  an  instantiation. 

4.  PPhaseConferSuppoitState  —  after  a  new  match  has  been  instantiated, 
this  state  calculates  the  right  hand  side  preference’s  support,  adds  the 
support  to  the  support  memories  and  collects  the  O-supported  reject  pref¬ 
erences. 

5.  PPhaseChunkingState  —  preference  phase  steps  the  execution  of  chunking 
from  this  state. 

6.  PPhaseORejectState  —  any  new  reject  preferences  with  0-support  are 
processed  to  remove  matching  preferences  from  preference  memory  and 
the  support  memories. 

7  PPhaseChangePMState  —  preference  phase  changes  preference  memory 
to  match  support  memory. 

8.  PPhaseFinishedState  —  when  preference  phase  finishes,  it  rests  in  this 
state. 

Preference  Phase  Slate  PPhaselmtialState 

P  PhaseRetractJnstantiationState 
PPhaselnstantiateMatchState 
PPhaseConferSupportState 
PPhaseChunkingState 
PPhaseORejectState 
PPhaseChangePMState 
I  PPhaseFinishedState 

Recognition  Memory’s  state  shares  six  memories  with  other  modules  of  Soar. 

•  WM  —  the  set  of  working  memory  elements.  WM  is  shared  with  10  and 
Decide. 

•  PM  —  the  set  of  preferences.  PM  is  shared  with  Decide. 

•  TM  —  essentially  a  union  of  working  memory  and  preference  memory. 
TM  is  shared  with  Decide. 
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•  IdencifierTable  —  the  set  of  identifiers  in  use  in  any  part  of  Soar.  The 
Identifier TabJe  is  global  to  all  modules  of  Soar. 

•  GM  —  is  the  set  of  goal  identifiers.  GM  is  read  from  Decide. 

•  cha.ngedslots  —  the  set  of  slots  changed  by  preference  phase.  This  is  read 
and  deleted  by  decide  to  tell  which  slots  decide  should  consider. 

^RM _ 

WM  :  P  WME 
PM  :  P  Preference 
;  TM  :P  TME 

Identifier  Table  :  P  Identifier 
GM  :  P  Identifier 
\  SPM  :  P  SP 
MS  -P  Match 
IS  :  P  Instantiation 
ISM  :  Preference  —*  Instantiation 
OSM  :  Preference  •—  Identifier 
ORM  :  P  Preference 
instantiation  :  Instantiation 
pphase^state  :  PreferencePhaseState 
changed-siots  :  P  Slot 
Chunking 

i  MS  =  {m  :  Match  '  m. production  €  SPM  AMatcbes^r^j^^  (m,  ‘VM .  WMif)  A 
m. binding nm. production. rootsl  Z  GM  IM] 

ran  OSM  C  GM 

SPM  Z 

TM  -  PreferenceTME\PM\  ^  WMETME(^WM\ 

V  p  :  ORM  • 

'  p  €  ran  UnaryP  A  (UnaryP’' [p)). preference  =  '  -  ' 


Recognition  memory  holds  six  local  memories. 

•  SPM  —  is  the  set  of  productions  m  Soar. 

•  MS  —  the  .se'  of  current  matches  for  the  productions.  Each  match  must  be 
for  a  production  in  production  memory,  must  match  the  current  contents 
of  working  memory,  and  all  of  the  production's  root  v-ariables  must  be 
bound  to  the  identifiers  of  goals  or  impasses. 

•  IS  —  the  set  of  instantiations  that  preference  phase  has  created  from  the 
matches. 
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•  ISM  —  the  I-support  memory.  This  memory  is  a  relatio.i  from  preferences 
to  the  instantiations  that  are  currently  supporting  them. 

•  OSM  —  the  0-support  memory.  This  memory  is  a  relation  from  prefer¬ 
ences  to  the  identifier  of  existing  goals  that  had  an  instantiation  I-support 
them. 

•  ORM  -  a  memory  of  the  O-supported  reject  preferences  that  preference 
phase  has  created  while  instantiating  matches  that  have  yet  to  be  pro¬ 
cessed. 

When  recognition  memory  is  initialized,  all  of  its  memories  are  empty  except 
for  the  production  memory.  The  production  memory  must  not  be  empty  so  that 
Soar  has  some  long  term  memories  to  use  in  performing  its  task;  otherwise  Soar 
would  impasse  indefinitely. 

_ InitRM _ 

RM 

pphase^state  =  PPhaseFimshedState 

:  IF  =  <z 
.  ISM  =  0 
OSM  -  0 
I  ORM  =  0 
WM  =  0 
PM  -  0 
SPM  0 


5.8  Support 

Support  is  Soar’s  basic  mechanism  for  determining  the  extent  of  preferences 
in  preference  memory.  Support  comes  in  two  flavors:  instantiation  support. 
I-support.  and  operator  support,  O-support.  Whenever  an  instantiation  is  cre¬ 
ated,  it  gives  instantiation  support  to  each  of  the  preferences  in  its  right  hand 
side.  When  the  instantiation  is  retracted,  it  withdraws  its  instantiation  support 
from  each  of  its  preferences.  Whenever  instantiations  that  are  creating,  modify¬ 
ing  or  applying  operators  create  a  preference  whose  identifier  is  in  the  transitive 
closure  of  their  match  goal’s  states  or  operators,  they  confer  operator  support 
to  these  preference.  The  operator  support  has  the  extent  of  the  match  goal  of 
the  instantiation,  and  so  is  not  retracted  when  the  instantiation  retracts. 
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This  section  defines  the  operators  matched  by  an  instantiation,  when  an 
instantiation  is  creating,  modifying  or  applying  an  operator,  and  then  combines 
these  into  a  definition  of  when  an  instantiation  0-supports  a  preference. 

An  instantiation  matches  an  operator  if  it  matches  a  goal’s  operator  slot  or 
operator  acceptable  preference. 

InstantiationsLHS Operators  :  Instantiation  x  P  TME  — ►  P  Identifier 

V  i  :  Instantiation-,  TM  :  P  TME  • 

3g  :  Identifier  |  g  =  MatchGoal{i. match,  TM)  • 

I  InstantiationsLHSOperators(i,  TM)  — 

I  {o  :  Identifier  :  makeWME[g, '  OPERATOR  o,  No)  £  i. match. Ihs  v 

I  maie  '  OPERATOR o,  i'es)  £  i. match. Iks} 

An  instantiation  creates  an  operator  if  it  makes  an  acceptable  or  require 
preference  for  an  operator  slot  of  a  goal. 

I  InstantiationsRHS Operators  :  Instantiation  x  P  TME  — ♦  P  Identifier 
1 _ 

I  Vi:  Instantiation-,  TM  :  P  TME  • 

I  InstantiationsRHSOperators{i ,  TM)  = 

{o  :  Identifier 

make UnaryPreference(MatchGoal{i. match.  TM), 

“  OPERATOR o. '  —  ')£  I. rhs  V 
j  make U'naryPreference{MatchGoal(i. match,  TM), 

I  ‘OPERATOR',0,  •!')  6  i.rA*} 

An  instantiation  only  confers  operator  creation  support  if  its  match  matched 
a  working  memory  element  whose  identifier  is  in  the  transitive  closure  of  the 
match  goal’s  state. 

Operator  Creation!  HS  :  P  TME  —  P  Instantiation 

\  _ 

V  TM  :  P  TME-,  i  -.  Instantiation  • 

I  £  OperatorCreationLHS(TM)  o 
(3  g  :  {MatchGoal{i. match,  TM)}  • 

(3  s  :  {GoalState{g,  TM)}  • 

(Ondjj^j^({TClTME{TM))i{s}),  TM)n 
WMETMEIi.match.lhsl  t  0))) 
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An  instantiation’s  right  hand  side  only  confers  operator  support  on  a  prefer¬ 
ence  if  the  preference’s  identifier  is  in  the  transitive  closure  of  an  instantiation’s 
operator  over  temporary  memory  and  the  instantiation’s  right  hand  side. 

Operator CreaiionRHS  :  P  TME  — ♦  (Instantiation  <-♦  Preference) 

V  TM  :  P  TME\  i  :  Instantiation-,  p  :  Preference  • 

{{i,p)  €  OperatorCreationRHS{TM))  <» 

(Preferences I d(p)  £ 

(TCIj’j^£(  TM  U  PreferenceTME^i.rhs))) 

(Instantiations RHS Operator s(i,  TM))) 

An  instantiation  confers  operator  creation  support  on  a  preference  if  its 
left  hand  side  is  an  operator  creation  and  the  right  hand  side  confers  operator 
creation  support  on  the  preference. 

[  OperatorCreation  :  P  TME  — ♦  (Instantiation  <-*  Preference) 

j  V  TM  :  P  TME-,  i  :  Instantiation;  p  ;  Preference  • 

(i,p)  £  OperatorCreation(TM) 

O  i  £  Operator CreationLHS(TM)  A 
(i,p)  £  OperatorCreationRHS(TM) 

An  instantiation  can  confer  operator  modification  support  if  its  left  hand 
side  matches  an  operator  and  its  match  matches  a  working  memory  element  of 
the  state. 

j  Operator ModificationLHS  :  P  TME  — ♦  P  Instantiation 

V  TAI  :  P  TME\  i  Instantiation  • 

I  i  £  Operator ModificationLHS(TM)  o 
I  (3  ?  :  {MatchGoal(i. match,  TM)}  • 

(5  J  :  {GoalState(g,  TM)}  • 

((OiIdjj^E(TCIj'^]^(TM)({s}),  TM)r. 

WMETME ^i. match. lhs(l)  0)  A 

(InstantiationsLHSOperators(t,  TM)  0))) 
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An  instantiation’s  right  hand  side  confers  operator  modification  support  on 
a  preference  if  its  identifier  is  in  the  transitive  closure  of  a  matched  operator. 

i  OperatorModificationRHS  :  P  TME  — ►  (Instantiation  «-•  Preference) 

V  TM  :  P  TME;  i  :  Instantiation;  p  :  Preference  • 

(i,p)  G  OperatorModificationRHS  (TM)  o 

(3  g  :  {MatchGoal(i. match,  TM)}  • 

Preferencesld(p)  € 

I  (TCIrpj^£(TM  u  PreferenceTME^i  rhs))) 

(InstantiationsLHS Operator s(i,  TM))) 

An  instantiation  confers  operator  modification  support  on  a  preference  if  the 
left  hand  side  is  an  operator  modification  left  hand  side  and  the  right  hand  side 
confers  operator  modification  support  on  the  preference. 

Operator  Modification  :  P  TME  — *  (Instantiation  — ♦  Preference) 

V  TM  :  P  TME;  i  :  Instantiation;  p  :  Preference  • 

I  (i,p)  €  Operator Modificatton(TM)  O 

!  i  G.  Operator ModificationLHS(TM)  A 
(t,p)  G  OperatorModificationRHS  (TM) 

An  instantiation  can  confer  operator  application  support  if  its  left  hand  side 
matches  its  match  goal’s  operator  slot  and  a  working  memory  element  in  the 
transitive  closure  of  the  match  goal’s  state. 

Operator ApplicationLHS  :  P  TME  — >  P  Instantiation 

TM  :  P  TME:  i  :  Instantiation  • 
i  €  Operator  ApplicationLHS  (TM) 

(3  g  :  {MatchGoal(i. match,  TM)}  • 

(5  5  ;  {GoalState(g ,  TM)}  • 

I  (do;  {GoalOperator(g,  TM)}  • 

j  makeWME(g, '  OPERATOR',  o.  No)  G  i.match.lhs  A 

I  (Ondj]^^((TCIrpj^^(TM))({s}),TM)n 

I  W ME  TM E  (;i.  match.  Uish  ^  0)))) 
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An  instantiation  can  confer  operator  application  support  on  a  preference  if 
the  preference's  identifier  is  in  the  transitive  closure  of  the  state. 

I  Operator ApplicationRHS  :  P  TME  —*  [Instanliatton  Preference) 

V  TM  :  P  TME',  i  :  Instantiation:  p  :  Preference  • 

(i,p)  E  Operator ApplicationRHS{TM) 

(3  g  :  {MatchGoal(i. match,  TM)}  • 

(3*  :  {GoalState(g,  TM)}  • 

Preferences Id{p)  €  TCI'j'^f-£{TM  PreferenceTME'ii.rhs)){{s})))) 

An  instantiation  confers  operator  application  support  on  a  preference  if  the 
left  hand  side  is  an  operator  application  left  hand  side  and  the  right  hand  side 
confers  operator  application  support  on  the  preference. 

j  Operator  Application  :  P  TME  — *  (Instantiation  <->  Preference) 

V  TM  :  P  TME,  i  :  Instantiation;  p  :  Preference  • 

(i,p)  ~  Operator Application(TM)  «• 

t  ~  Operator ApplicationLHS{TM)  A 
(t,p)  €  Operator  ApplicationRHS  (TM) 

An  instantiation  confers  operator  support  on  a  preference  if  the  instantiation 
confers  operator  creation,  modification  or  application  support  on  the  preference. 

j  0 Support  :  P  TME  — »  (Instantiation  •-*  Preference) 

^  V  TM  :  P  TME;  i  :  Instantiation;  p  :  Preference  • 

(t,p)  S  OSuppori(TM)  <=> 

(*iP)  €  (OperatorCreatton(TM)i^ 

,  Operator  Modification)  TM)u 

Operator  A  pplication(TM)) 


5.9  Preference  Phase  Operations 

The  preference  phase  has  eight  states;  an  initial  state,  a  final  state,  a  state  for 
retracting  instantiations,  a  state  for  instantiating  matches,  a  state  for  conferring 
support,  a  state  for  chunking  an  instantiation,  a  state  for  0-rejecting  preferences 
and  a  state  for  changing  the  contents  of  preference  memory  based  upon  the 
contents  of  the  support  memories.  This  section  specifies  the  operations  of  these 
states  in  seven  sections. 
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5.9.1  Initialize,  Finish,  Reset  and  Quiescence 

The  preference  phcise  waits  in  its  final  state  until  it  is  initialized  with  the  PPha- 
selaitiedize  operation. 

, _ PPhaselnitialize _ 

j  ARM 

I  pphase^siate  =  PPhaseFinxshedState 

\ 

\  pphase  ^state'  =  PPhaselmtialState 


The  PPhaseReset  operation  resets  the  preference  phase  state  machine.  The 
set  of  weiiting  0-reject  preferences  is  emptied  so  that  the  next  execution  of  the 
preference  phase  does  not  reject  things  that  no  longer  have  O-supported  rejects. 

_ _ PPhaseReset _ 

I  ARM 

!  pphase  ^state'  —  PPhaseFinishedSlate 

I 

i  ORM'  =  0 


The  top  level  state  machine  checks  the  state  predicate.  Quiescence,  before 
it  allows  the  preference  phase  to  run.  The  system  is  quiescent  if  there  is  no 
instantiation  waiting  to  be  retracted,  or  match  waiting  to  be  instantiated. 

_ Quiescence  . _ 

r  RM 

-  [3  I  :  IS  •  i. match  $  MS ) 

-(5m:  MS  •  -<  {3  i  :  IS  •  i. match  —  m)) 


5.9.2  Retracting  Instantiations 

Preference  phase  begins  its  execution  by  moving  from  the  initial  state  into  a 
state  that  retracts  instantiations. 

_ P  PhaseStartRetractInstantiatxon _ 

!  ARM 

I 

j  pphase -State  =  PPhaselmtialState 

I 

I  pphase -State'  =  PPhaseRetractInstantiationState 


111 


When  there  exists  an  instantiation  in  instantiation  memory  whose  match 
is  no  longer  in  the  match  set,  then  PPhaseRetractlnstantiation  removes  the 
instantiation  from  the  instantiation  set.  The  instantiation  support  for  each 
preference  of  the  right  hand  side  is  removed  from  I-support  memory. 

_ PPhaseRetractlnstantiation _ 

ARM 

pphasestate  —  PPhaseRetractInstantiationState  =  pphase^state' 

3i  .  IS  \  i. match  ^  MS  • 

I  {lS'  =  IS\{i}\ 

!  ISM'  =  ISM  \  {p  :  i.rhs  •  (p  —  x)}) 


5.9.3  Instantiate  Match 

When  there  is  no  instantiation  in  the  instantiation  set  whose  match  is  no  longer 
satisfied,  preference  phase  moves  into  the  instantiate  match  state 

_ PPhaseStartInstantiateMatch _ 

ARM 

pphasestate  =  P  PhaseRetractlnstantiationState 

^  (5  t  :  /S  •  i. match  ^  MS) 

pphasestate'  —  PPhaselnstantiateMatchState 
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PPhaselnstantiateMatch  selects  a  match  from  the  match  set  that  does  not 
yet  have  an  instantiation  and  instantiates  it.  An  instantiation  is  created  and 
added  to  the  instantiation  memory,  and  recognition  memory’s  instantiation  vari¬ 
able  is  set  to  this  new  instantiation.  Each  newly  generated  preference  is  given 
a  new  instance  numbering  in  PM  # 

I _ PPhaaelnatantiateMatch _ 

j  AiZM 

1  pphaae  ^state  =  PPhaselnstantiateMatchState 

j  Em:  MS  j  —  (E  i  :  75  •  i. match  =  m)  • 

I  (3  >  ■  Instantiation;  b  :  Binding  { 
j  i. match  =  m  A 

j  i.lhs  =  m. production. Ihs  A 

'  i.  matching  = 

Instantiate  ConditionMatching{  m .  matching , 

m. production. Ihs  \  ran  PositiveCondition.  m. binding)  a 
b  ConsistentExtension  m. binding  A 

I  b  Covets  {[J(MakesComponents^m. production. rhsl)  A,  Variable)  A 

i.  binding  =  fe  A 

t.rhs  =  {MakesPreference{b))^m. production. rhs^  • 

I  instantiation'  =  >  A 

/5'=75o{»}a 

I  E  new  ^preferences  :  P  Preference  I  new  -preferences  =  (i.rhs  \  PM)  • 
max -preference'  =  max -preference  —  new -preferences  • 

I  E/  :  new -preferences  ({max -preference  1)  •  ■  max -preference')  • 

PM#'  =  FM#©/) 

pphase  -State'  =  PPhaseConferSupportState 
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5.9.4  Conferring  Support 

The  PPhaseConfeiSuppoTt  operation  adds  support  to  the  I-support  memory  for 
each  right  hand  side  preference,  and  if  the  preference  is  0-supported  then  it  is 
given  0-support  for  the  match  goal.  Each  reject  preference  that  has  0-support 
is  added  to  the  memory  of  0-reject  preferences.  After  PPhaseConferSupport 
operates,  chunking  is  stepped  for  the  new  instantiation. 

. _ PPhaseConferSupport _ 

{  ARM 

j  pphase  state  —  PPhaseConferSupportState 

ISM'  =  ISM  {p  *  tastantiatioTi t T*}is  s  ^Pi  lastaTitxatioTi^'^  /\ 

OSM'  =  OSMu 
{p  ;  instantiation .rhs  | 

j  (instantiation,  p)  G.  OSupport(TM)  • 

I  (p,  MatchGoal(instantiation.match,  TM))}  A 

i  ORM'  =  ORMi^ 

{p  :  instantiation.rhs  n  ran  UnaryP  • 

(UnaryP'~  (p)). preference  =  '  — '  A  (instantiation,  p)  G  OSupport(TM)} 

j  Chunking  Initialize 

I  pphase  state'  =  P Phase  ChunkingState 

5.9.5  Stepping  Chunking 

PPhaseStepChunking  steps  the  chunking  state  machine  through  chunking  the 
instantiation. 

_ PPhaseStepChunking _ 

'  ARM 

! - 

j  pphase  state  =  P Phase  ChunkingState  ~  pphasestate' 

I  ChunkingStep 

'i _ 

Chunking  may  return  a  new  instantiation  or  it  may  produce  no  new  instanti¬ 
ation  if  the  input  instantiation  is  for  the  top  goal.  The  variable  chunkingsesult 
signals  the  existence  of  a  new  instantiation  to  preference  phase. 


If  there  is  a  new  instantiation,  it  must  have  its  support  calculated,  so  pref¬ 
erence  phase  returns  to  the  confer  support  state.  Once  the  support  has  been 
conferred,  the  new  instantiation  will  be  sent  back  into  chunking  so  that  its  effects 
may  be  chunked. 

_ P Phase  Chunking Retumedlnstantiation _ 

ARM 

pphase^siaie  =  PPhaseChunkingSiate 

I  ^  pre  Chunking 

1 

chunking  ^result  =  New  Instantiation 
pphase -State'  =  P  Phase  ConferSupportState 

If  no  instantiation  has  been  generated  by  chunking,  the  preference  phase 
returns  to  the  instantiate  match  state  to  pick  a  new  match  for  instantiation. 

_ PPhaseChunkingNoInstantiation _ 

j  ARM _ 

j  pphase -State  —  P  Phase  Chunking  State 

i 

j  -  pre  Chunking 

chunking -result  =  No  Instantiation 

pphase -State'  =  P  Phase  Instantiate  MatchState 


5.9.6  O-rejects 

When  there  are  no  more  matches  to  instantiate,  preference  phase  starts  the 
processing  of  0-rejects. 

_ PPhaseStartO  Reject _ 

ARM 

j  pphase -State  =  PPhaselnstantiateMatchState 
j  V  m  :  MS  •  5  i  :  75  •  i. match  =  m 
I  pphase -State'  =  P Phase O Re jectState 
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PPhaseORejectPreferences  chooses  an  O-reject  preference  from  the  0-reject 
memory  and  deletes  it  from  memory.  It  also  deletes  from  preference  memory  all 
preferences  that  share  the  same  identifier,  attribute  and  value.  The  I-support 
and  O-support  memories  are  also  cleaned  of  all  support  for  the  rejected  pref¬ 
erences.  including  the  O-reject  itself.  The  operation  ([Spi89]  99)  restricts  a 
relation  or  partial  function  to  apply  only  to  those  elements  of  its  domain  that 
are  not  in  the  provided  set. 

_ PPhaseORejectPreferences _ 

ARM 

pphasestate  —  P  Phase  ORejectState  =  pphase  _state' 

5r  :  ORM,  ur  :  UnaryPreference  ur  —  UnaryP'~  (r)  • 

(ORM' =  ORM  \  {r}  A 
[3  P  :  P  Preference 

P  ~  UnaryP ^{up  :  UnaryP'~  \{{PM  u  dom  ISM)  A  ran  UnaryP)) 
up. id  =  ur.id  Z'  up. attribute  =  ur. attribute  A  up. value  —  ur. value} 
BinaryP^{bp  :  BinaryP"  ^^(PM  o  dom  ISM)  ~  ran  BinaryP)l 
bp. id  =  ur.id  A  bp. attribute  =  ur. attribute  A  bp. value  =  ur. value}) 
{r}  • 

PM'  =  PM  \  P  A 

ISM'  =  P^ISM  A 
'  OSM'  =  P^  OSM)) 


5.9.7  Changing  Preference  Memory 

When  all  of  the  0-rejects  have  been  processed,  preference  phase  starts  changing 
preference  memory  to  correspond  with  the  contents  of  the  support  memories. 

_ P  PhaseStartChangeP  M _ 

I  ARM 

\  pphase^state  =  P  Phase  O  Re jectState 

I 

j  ORM  =  0 

!  pphase  ^state'  =  PPhaseChangePM  State 
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If  there  is  a  preference  that  has  support  in  I-support  memory  or  0-support 
memory  that  is  not  in  preference  memory,  then  it  is  added  to  preference  memory, 
and  its  slot  is  added  to  the  set  of  changed  slots. 

_ P Phase  AddPreference _ 

ARM 

pphase  -State  =  PPhaseChangePMState  =  pphasestate' 

3  p  :  dom  ISM  u  dom  OSM  \  p  £  PM  • 
i  {PM'  =  PM  ^  {p}  A 

changed  slots'  =  changedslots  o'  {{ p.  id,  p.  attribute)}) 


If  there  is  a  preference  in  preference  memory  that  does  not  have  I-support 
or  0-support,  it  is  removed  from  preference  memory,  and  its  slot  is  added  to 
the  changed  slots. 

_ PPhaseRemovePreference _ 

:  ARM 

\  pphasestate  =  PPhaseChangePMState  —  pphasestate' 

3p  :  PM  1  p  £  dom  ISM  o  dom  OSM  • 

{PM'  =  PM  \  {p}  A 

'  changedslots'  =  changedslots  J  {{p. id,  p. attribute)})) 


When  there  are  no  more  differences  between  the  supported  preferences  and 
the  contents  of  preference  memory,  preference  phase  is  complete. 

_ PPhaseFinish _ 

ARM 

pphasestate  =  PPhaseChangePMState 
-  {3p  :  PM  •  p  £  dom  ISM  o  dom  OSM) 

I  -  (5  p  :  dom  ISM  •  p  £  PM) 

!  pphasestate'  =  PPhaseFinishedState 
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PPhaseStep  moves  the  preference  phase  state  machine  through  one  of  its 
possible  transitions. 

PPhaseStep  = 

PPhaseStartRetractlnstantiation  V  P PhaseRetracilnstaniiation  v 
PPhaseStartlnstantiateMatch  v  PPhaselnsiantiateMaich  v 
PPhaseStartO Reject  v  PPhaseORejectPreferences  v 
PPhaseStartChangePM  V  P Phase AddPreference  V 
PPhaseRemovePreference  V  PPhaseFtntsh 
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Chapter  6 

lO 


This  chapter  specifies  Soar’s  mechanism  for  communicating  with  the  external 
world,  called  SoarlO  or  10  for  short.  lO’s  operation  is  graphically  represented  in 
Figure  6.1.  lO’s  two  state  machines,  LiputCycle  and  OutputCvcJe,  are  stepped 
by  the  top  level  state  machine.  The  InputCycle  reads  InputStructures  from 
InputChannek  and  places  their  results  on  InputAttributes  on  the  top  state,  and 
in  the  transitive  closure  of  the  value  of  the  input  attribute.  The  OutputCy- 
cle  packages  the  transitive  closures  of  output  attributes  of  the  top  state  into 
OutputStruclures  and  ships  them  out  OutputChannek. 


6.1  Channels,  Attributes  and  lO  Mappings 

The  user  of  Soar  provides  10  with  two  fixed  sets:  InputCbannel  and  Out- 
putCbanneJ  For  the  purposes  of  the  specification  we  represent  these  channels 
as  a  sets  of  constant  names  for  the  channels.  The  implementation  may  choose  to 
represent  a  channel  as  a  function  name,  or  a  pointer  to  a  function;  in  essence  it 
IS  a  computational  operation  that  provides  input  perceptions  or  receives  motor 
operations. 

The  user  also  specifies  two  sets  of  InputAttributes  and  OutputAttributes. 
The  InputAttributes  are  the  attributes  that  input  channels  use  to  augment 
the  top  level  state  with  their  perceptions.  The  user  provided  fnputAfapping 
maps  each  InputCbannel  to  the  Input  Attribute  that  receives  its  perceptions. 
Similarly,  the  OutputAttributes  are  the  attributes  of  the  top  level  state  from 
which  lO  collects  their  transitive  closure  and  ships  it  to  the  OutputChannel 
specified  by  the  OutputMapping. 

No  channel  can  be  both  an  input  and  an  output  channel,  and  no  attribute 
can  be  both  an  input  and  an  output  attribute. 
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Soar 
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InputChannel  :  P  Constant 
InputAttribute  ;  P  Constant 
OutputChannel  :  P  Constant 
OutputAttribute  :  P  Constant 

disjoint  (InputChannel ,  OutputChannel) 

disjoint  (InputAttribute,  OutputAttrihute) 


]  InputMapping  :  InputChannel  — ►  InputAttrilute 
I  OutputMapping  :  OutputAttrihute  OutputChannel 

6.2  Output  Structures 

The  OutputCycIe  collects  output  into  packages  called  OutputStiuctures.  On 
each  cycle  all  OutputAttributes  have  the  working  memory  elements  in  their 
transitive  closure  collected  into  an  OutputStructure  and  shipped  out  their  cor¬ 
responding  OutputChannel.  The  predicate  of  the  output  structure  ensures  that 
the  set  of  working  memory  elements  is  transitively  closed  from  the  object  iden¬ 
tifier. 


_ OutputStructure _ 

!  object  ;  Identifier 
I  wmes  :  P  WME 

0{ld\yj^£{{TCI^j^j£{wTnes)){{object}),  wmes)  =  rvmes 


6.3  Input  Structures 

On  each  InputCycIe.  all  of  the  InputChannek  are  polled  to  produce  changes  to 
working  memory.  These  changes  are  bundled  into  InputStiuctures.  There  are 
three  types  of  input  structures:  a  NewInputSttucture,  a  ModifyInputStructure 
and  a  DeietelnputStructure. 

A  NewInputStructure  tells  Soar  to  augment  the  top  state  with  a  working 
memory  of  value  new_object  and  the  attribute  of  the  input  channel,  and  to  also 
add  all  of  the  elements  in  wmes. 

. _ NewInputStructure _ 

new  ^object  :  Identifier 
wmes  :  P  WME 

Ofrd^^£;((TCf^jyfjpfu;mej))({new_ci6;ect}),  wmes)  =  wmes 


121 


A  ModifylnputStructure  tells  Soar  to  find  the  augmentation  of  the  top  state 
that  holds  the  input  channel’s  attribute  and  the  modify  ^object  value.  Soar 
must  add  all  of  the  elements  in  the  adds  set,  and  delete  all  of  the  elements  in 
the  deletes  set. 

_ ModifylnputStructure _ 

modify^object  :  Identifier 
adds,  deletes  :  P  WME 


The  DeletelnputStructure  tells  Soar  to  delete  the  augmentation  of  the  input 
channel’s  attribute  and  the  deiete^object  value  and  all  of  the  elements  in  its 
transitive  closure. 

, _ DeletelnputStructure _ 

I  delete-object  :  Identifier 


The  free  type  InputStructure  is  used  to  construct  a  disjunctive  type  of  the 
basic  input  types. 

InputStructure  New {(NewInputStructure)) 

I  Modify  {(ModifylnputStructure)) 

I  Delete  {(DeletelnputStructure)) 


6.4  Cycles  of  lO 

As  Soar  behaves,  it  reads  in  parallel  from  all  of  its  input  channels.  Each  in¬ 
put  channel  is  free  to  send  more  than  one  InputStructure  to  the  system.  A 
CvcJeOfInput  is  defined  to  capture  the  input  for  a  single  cycle.  It  maps  each 
InputChannel  to  the  set  of  inputs  read  during  that  cycle. 

CycleOfInput  ==  InputChannel  — *  P  InputStructure 
CycleOfOutput  ==  OutputChannel  OutputStructure 

Similarly,  each  parallel  ply  of  Soar’s  motor  actions  are  captured  in  a  partial 
function  from  OutputChanneJs  to  the  single  possible  OutputStructure  that  Soar 
produced. 

6.5  lO  State 

10  requires  two  state  machines:  one  for  the  InputCycle  (Figure  6.2)  and  one  for 
the  OutputCycIe  (Figure  6.3). 
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The  InputCyde  requites  three  states. 

1.  InputCyclelnitialState  —  the  initial  state  of  the  machine 

2.  InputCycleReadState  —  the  state  in  which  a  single  InputStructure  is  read 
from  an  InputChannel 

3.  InputCycleFinishedState  —  the  final  state  of  the  machine 


InputCycleState  InputCyclelnitialState 
I  InputCycleReadState 
InputCycleFinishedState 
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The  OutputCycie  also  requires  only  three  states; 

1.  InputCyclelnitialState  —  the  initial  slate  of  the  machine. 

2.  InputCycleReadState  —  the  state  in  which  an  OutputStructure  is  col¬ 
lected  from  the  top  level  state  and  sent  out  an  OutputChannel. 

3.  InputCycleFinishedState  —  the  final  state  of  the  machine. 


OutputCycleState  ::=  OutputCyclelnitialState 
i  OutputCycleSendState 
OutputCycleFinishedState 


The  lO  state  schema  shares  working  memoty  and  goal  memory  with  the 
other  major  modules  of  Soar.  The  lO  system  searches  working  memory  to  keep 
updated  the  top  state  of  the  goal  stack.  If  there  is  no  top  state,  then  TopState 
is  set  to  a  special  symbol  '  NIL  '. 
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The  schema  holds  state  counters  input_cycle^state  and  output^cyclestate 
for  the  two  10  state  machines. 

The  specification  of  JO  takes  a  traditional  approach  to  modeling  input /output 
behavior  by  using  sequences  of  inputs  to  model  the  sequence  of  inputs  that  Soar 
would  encounter  over  time,  and  by  recording  its  outputs  over  time  in  a  sequence. 

inputs  is  the  sequence  of  CydeOilDput  that  models  a  possibly  infinite  stream 
of  cycles  of  input  that  Soar  will  perceive  as  it  behaves,  outputs  is  the  initially 
empty  sequence  of  CycleOfOutput  in  which  10  records  Soar’s  output  over  time. 

Other  approaches  to  modeling  the  input/output  behavior  of  a  computational 
system  are  possible.  For  example,  the  operations  that  read  input  from  the 
sequence  of  inputs  can  be  replaced  by  an  under-specified  operation  that  produces 
any  one  input  from  the  set  of  all  possible  inputs.  Similarly,  the  output  operation 
can  be  under-specified  to  have  no  effect. 

_/0 _ 

I  WM  :  P  WME 
GM  :  P  Identifier 
TopState  :  Identifier  o  {*  NIL  '} 
inputs  :  seq  Cycle  Of  Input 
input ^cycle^state  :  InputCycleState 
outputs  ■■  seq  CycleOfOutput 
output ^cycle state  :  OutputCycleState 

3g  :  GM  ,  makeWME{g, '  OBJECT ',  ‘  NIL  ')  e  WM  • 

((3  s  :  Identifier  •  makeWME(g, '  STATE  ',  s)  £  WM)  => 

I  (3  s:  Identifier  .  make  WME(g, '  STATE  ' ,  s)  c  WM  • 

'i  TopState  =  S) 

I  -(5s:  Identifier  •  makeWME[g, '  STATE  s)  €  WM)  => 

!  TopState  =  'NIL') 


10  starts  with  both  state  machines  in  their  finished  state  and  an  empty 
sequence  of  outputs. 

_ Initio _ 

10 

input  sycle  state  =  InputCycleFinishedState 
output  sycle  state  =  OutputCycleFinishedState 
I  outputs  =  0 


6.6  The  Input  Cycle 

The  InputCycIe  is  defined  using  five  transitions. 
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1.  InputCyclelnitialize  —  this  transition  initializes  the  state  machine. 

2.  Sta.ttReadInputCha.nneI  —  this  transition  starts  the  processing  of  input. 

3.  ReadInputChannel  —  this  transition  is  a  very  complex  composite  tran¬ 
sition.  With  each  step,  it  reads  one  part  of  any  of  the  three  types  of 
InputStTuctures. 

4.  InputCycieFinish  —  this  transition  finishes  the  InputCycle  when  all  of  the 
input  has  been  read. 

5.  InputCycieReset  —  this  transition  resets  the  state  machine. 

6.6.1  Legal  Input 

The  InputCycle  is  the  only  place  in  the  specification  of  Soar  that  an  error 
condition  is  checked.  An  example  of  an  errorful  input  is  aji  input  structure  that 
attempts  to  remove  working  memory  elements  that  are  not  in  the  transitive 
closure  of  its  input  attribute. 

The  specification  can  check  that  its  input  sequence  is  correct  before  exe¬ 
cution,  but  as  the  implementation  does  not  have  the  full  sequence  of  inputs 
available  at  start  up  time,  it  must  check  them  one  by  one.  For  consistency  we 
have  specified  that  each  cycle  of  input  is  checked  for  correctness  as  they  are 
popped  from  the  sequence  of  inputs.  This  subsection  defines  the  legal  input 
predicate  to  test  each  input 

An  identifier  is  an  InputLink  of  an  attribute,  if  it  there  is  an  augmentation 
of  the  top  state  in  working  memory  that  holds  it  as  a  value. 

InputLink^  :  P  WME  x  Identifier  x  InputAttrihute  *->  Identifier 

V  WM  :  P  WME:  s  :  Identifier:  InputAttrihute  :  InputAttrihute', 
id  :  Identifier:  link  :  Preference  • 

InputLink{(  WM .  s,  InputAttrihute),  id) 

(5  u)  :  WM  •  w. id  =  s  /\  w. attribute  =  InputAttrihute  A 
I  ui. value  =  »d  A  w. context -acceptable -preference  =  No) 

Legallnput  checks  the  first  CycIeOfInput  in  the  inputs  sequence  for  several 
properties: 

•  that  no  new  and  modify  are  for  the  same  object 

•  that  no  new  and  delete  are  for  the  same  object 

•  that  no  delete  and  modify  are  for  the  same  object 

•  that  no  two  news  are  for  the  same  object 

•  that  no  two  modifies  are  for  the  same  object 
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•  that  the  adds  of  different  modifies  are  disjoint,  and  that  one  modify  is  not 
adding  what  another  is  deleting 

•  that  a  NewInputStructure  is  for  an  InputLink  that  does  not  exist  on  the 
top  state 

•  that  a  DeieteInputStructure  is  for  an  existing  InputLinlr  and 

•  that  a  ModifylnputStructure  is  for  an  existing  InputLink,  and  that  its 
adds  and  deletes  modify  the  transitive  closure  of  the  input  object. 


_ Legalinput - 

10 

i  V  channel  :  InputChannel • 

V  wl,  is2  :  inputs(l){channel)  • 
isl  c  ran  New  a  ts2  c  ran  New  => 

((New~'(tal))  new^object  =  (New'’ (ts2)).new-object  =>  =  is2)  A 

wl  €  ran  Modify  A  ts  2  €  ran  Modify  => 

[(Modify''  [tal)).  modify  ^object  — 

[Modify'’  {is2)).modify^ob]ect  =>  wl  =  is2  a 
I  disjoint  {[Modify''[tsl)).adds,[Modify''[is2)).adds)  a 

disjoint  {[Modify" (tsl)). adds,  (Modify" [is2)). deletes))  a 
wl  €  ran  New  a  is2  €  ran  Modify  ^ 

[[New"  [tsl)).new^object  yt  [Modify"  [is2)). modify  ^object)  A 
J5l  €  ran  New  a  ii2  £  ran  Delete  => 

[[New" [ts\))  new^object  -t.  [Delete" [is2)). delete -object)  a 
i«l  £  ran  Delete  A  is2  £  ran  Modify  => 

[[Delete" [is2)).delete-object  [Modify"  [is2)). modify -object) 

«  channel  InputChannel  •  V  w  :  tnputj(l)(c/iaTine/)  • 

IS  £  ran  New  => 

(-  lnputLink[[WM .  TopState,  InputMapping[channel)), 

[New" [is)). new -object))  a 
IS  £  ran  Delete  => 

InputLink[[WM .  TopState,  InputMapping[ channel)), 

I  [Delete" [is)). delete-object)  a 

IS  £  ran  Modify  => 

[ InputLink [[  WM ,  TopState,  InputMapping[channel)), 

[Modify" [is)). modify -object)  a 
[[Modify"  [is)),  deletes 

C  0^d^rJ^£[[TCI^rr^£{WM))[{[Modify"[ls)).modlfy-obJect}).  WM)  a 

[[Modify"  [is)). adds 

C  Ond-^j^£[[TCIy^f  j^£[WM  [Modify"  [is)). adds)) 

[{[Modify" [is)). modify-object}),  WM  j  [Modify"  [is)). adds)))) 
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Although  the  specification  defines  the  conditions  of  acceptable  input,  it  does 
not  specify  how  the  implementation  should  handle  unacceptable  input. 

6.6.2  Initializing  and  Starting  the  InputCycle 

InputCyclelnttiadize  moves  the  InputCycle  state  machine  into  its  initial  state. 

_ InputCyclelnitialtze _ 

AlO 

input  ^cycle^state  =  InputCycleFinishedState 
input  ^cycle  ^state'  =  InputCyclelnitialStaie 


StartReadlnput  moves  the  machine  into  the  InputCycleReadState  to  begin 
reading  input  The  whole  CycIeOflnput  is  checked  for  legality  using  the  Legal- 
Input  predicate. 

_ StartReadInput _ 

A 10 

Legalinput 

input^cyclestaie  r  InputCyclelnitialState 
input ^cycle ^state'  -  InputCycleReadState 


6.6.3  Reading  NewInputStructures 

When  the  first  CycIeOflnput  holds  a  NewlnputStructure.  ReadNewInputStruc- 
tureObject  reads  in  its  object  Chunking's  TraceWME  operation  is  called  to 
give  the  working  memory  element  a  new  instance  number. 

_ Reads  exulnputStructure  Object _ 

A 10 

input-cycle^state  =  InputCycleReadState  =  input  ^cycle  state' 

3  tc  :  InputChannel  ic  €  dom(mp«t5(l))  • 

r  la  :  Input  Attribute  la  ~  InputMappingi  ic)  • 

3  n  ■.  inputs{  l)(ic)  ''  ran  Sew.  u:  ;  WME 

makeH’ME{TopState.ic.{S'ew''(n)].new-ob)ect,  No)  ^  \VM  a 
u'  =  rnakeWME{TapState.ic,{Ne'w'' {n)).ne\i;sb}ect.  No)]  • 

(  WAf'  =  H'lV/ _  {in}  A 
TraceWME) 
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After  the  top  state  has  been  augmented  with  the  object,  ReadNewInput 
StruclureWME  reads  in  one  of  the  new  working  memory  elements,  and  destruc 
tively  removes  it  from  the  NewlnputStructure. 

_ ReadNewInpritStructure  WME _ 

AIO 

input  ^cycle^state  =  InputCycleReadState  =  input  ^cycle^state' 

I 

[  5  tc  :  InputChannel  |  ic  £  dom(mpttts(l))  • 

[  5  ta  :  Input  Attribute  \  la  =  InputMapping{ic)  • 

j  an:  input3{l){ic)  n  ran  New  • 

I  3N  :  NewlnputStructure  \  N  =  New^ln)  A 

make  WME(  TopStale,  la,  N .new-object.  No)  £  WM  • 

3  w  :  N.wmes  !  w  ^  WM  • 

'  3  TV'  :  NewlnputStructure  ' 

N' .new -object  —  N .new -object  a 
I  N'  wmea  =  N  wmes  \  {to}  • 

(  WM'  =  WM  u  {to}  A 
Trace  WME  a 
inputi'(l)  =  mpt<t*(l)® 

{»c  — *  (inputs(l)(tc)  \  {n})  o  {TVeio(TV')}}  a 
I  tat/ (inputs')  =  tail(inputs)) 


When  all  of  the  working  memory  elements  have  been  read  in,  ReadNewLi 
putStructureDone  pops  the  input  from  the  first  cycle  of  input. 

_ _ ReadNewInputStructureDone _ 

^  A/0 

1 _ 

input -cycle  state  =  InputCycleReadState  =  input -cycle  state' 

3  ic  :  InputChannel  i  tc  £  dom(tnputs(l))  • 

j  la  :  InputAttribute  \  la  =  InpulMapping{ic)  • 
j  5  n  :  inputs)  l)(;c)  ^  ran  New  • 

3  N  :  NewlnputStructure  \  N  =  New~~{n)  a 
I  make  WME  {TopState,  la,  N  .new -object,  No)  £  WM  • 

{{N .wmes  =  0  A 

!  tnputs'(l)  =  mputs(l)  ©  {tc  — •  inputs(l)(tc)  \  {n}})  A 

tat/(  inputs')  =  tat/(tnputs)) 
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ReadNewInputStructure  is  the  composite  operation  for  reading  an  entire 
NewInputStiucture. 

ReadNewInputStructure  =  ReadNewInputStructure  Object  v 
ReadNewInputStructure  WME  v 
ReadNewInputStructureDone 


6.6.4  Reading  ModifyInputStructures 

When  there  is  a  ModifylnputStructure  in  the  first  CycleOfluput,  ReadModify- 
LnputStTuctuTeAdd  reads  in  one  of  the  elements  that  it  should  add,  and  deletes 
the  element  from  the  set  of  adds. 

_ ReadModifyInputStructureAdd _ 

;  SIO 

input  ^cycle^atate  =  IrputCycleReadState  =  input  _cycle^state' 

!  zic  :  InputCI'  r  1  1  ic  €  dom(»nputs(l))  • 

zia  :  Input  ’  tribute  la  =  InputMapping  ( »c)  • 

5  rr  .  yutj(l)(tc)  n  ran  Afetu  • 

z  M  :  ModifylnputStructure  j  M  =  Modify''  {m)  A 

makeWME(TopState,  la,  M .modify-object.  No)  €  WM  • 

I  3  u)  :  Af  adds  \  w  i  WM  • 

^  3M'  ■  ModifylnputStructure  ' 

1  M' .modify ^object  =  M .modify ^object  A 

M' .adds  =  M' .adds  \  {«;}  A 
I  M' .deletes  —  M .deletes  • 

;  (  WM'  =  WM  u  {w}  A 

1  Trace  WME  a 

;Tiput5'(l)  =  xnput5(l)0 

{ic  —  (tnputs(l)(ic)  \  {m})  u  {Modify{M')}}  a 
;  tail(inputj')  =  tail{inputs)) 
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ReadModifyInputStructureDelete  reads  in  a  delete  of  a  modify,  and  removes 
the  element  from  the  modify’s  delete  set. 

_ ReadModifyInputStructureDelete _ 

j  \IO 

input  ^cycle  state  =  InputCycleReadState  =  input  sycle  state' 

3  ic  :  InputChannel  I  tc  G  dom(mput5(l))  • 
i  3  in  :  InputAttribute  \  ia  =  InputMapping[ic)  • 

3  m  -.  inputs(l)(ic)  tan  New  • 

3  A/  :  Modify InputStructure  1  M  =  Modify" {m)  A 
makeWME{TopState,  ta.  M  .modifysbjeci.  No)  £  WM  • 

3  w  :  M .  deletes  i  w  G  WM  • 
j  3  M'  ;  Modify  InputStructure  | 

M' .modifysbject  =  M  .modify-object  a 
M'  deletes  =  M' .deletes  \  {uj}  a 
M' .adds  —  M .adds  • 

(  WM'  =  WM  \  {w}  A 
inputs' [1)  =  inputsil)® 

{tc  — *  input4(l)(tc)  \  {m}}  A 
tail{inputs')  =  tail{inputs)) 


When  all  of  the  changes  have  been  processed,  ReadModifvInputStructure 
Done  pops  the  modify  from  the  first  cycle  of  inputs. 

_ ReadModifylnputStructureDone _ 

A/D 

input  sycle  state  =  InputCycleReadState  =  input  sycle  state' 

3  tc  :  InputChannel  !  tc  G  dom(mpiit5(l))  • 

3  la  :  InputAttribute  la  =  InputMapping[iL)  • 

3m:  input5(l)(  tc)  ran  New  • 

3  Af  :  Modify  InputStructure  ■■ 

M  —  Modify" {m)  a  M.adds  =  M. deletes  =  0  • 

(mput5'(l)  =  inputs)!)  0  {ic  ^  inputs(l)(tc)  \  {m}}  A 
tail{inputs')  =  tail(inputs)) 


ReadModifylnputStructure  is  the  composite  operation  that  joins  all  of  the 
operations  for  reading  a  ModifyInputStructure. 

ReadModifyInputStructure  =  ReadModifyInputStructureAdd  v 
ReadModifyInputStructureDelete  v 
ReadM  odify  InputStructure  Done 
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6.6.5  Reading  DeleteInputStructures 

ReadDeletelnputStructuie  pops  a  DeietelnputStructure  from  the  first  Cycle- 
Oftnput,  and  removes  the  associated  InputLink.  The  working  memory  elements 
in  the  transitive  closure  of  the  link  are  not  explicitly  deleted.  The  working  mem¬ 
ory  elements  that  are  no  longer  accessible  from  the  context  stack  will  eventually 
be  removed  by  decide. 

_ ReadDeletelnputStructure _ 

A 10 

input  ^cycle^state  =  InputCycleReadState  =  input -cycle  state' 

5  »c  :  fnputChannel  ;  ic  €  dom(mputi(l))  • 

5  »a  ;  InputAttribute  la  =  InputMapping{ic)  • 

^  n  d  .  inputs{l/^  '•')  P  ran  Delete  • 

{WM' =  WM\ 

{■makeWME(TopState.ia,(Delete''{d)).delete-object.  iVo)}  a 
iriputs'(l)  =  inpu<j(l)© 

{ic  — *  mpu<4(l)( tc)  \  {d}}  A 
tail(inputs')  —  tail(tnputs)) 


6.6.6  Reading  an  Input  Channel 

ClosebiputChannel  will  close  any  channel  that  has  no  remaining  input  struc¬ 
tures. 


_ CloseInputChannel _ 

A/0 

input -Cycle  state  =  InputCycleReadState  —  input -cycle  state' 
Top  State  "NIL  * 

5  »c  :  InputChannel  !  ic  €  dom(mputj(l))  • 

(inp«t»(l)(»c)  =  0  A 
mputi'(l)  =  {»c}  mput5(l)  A 
tailiinputs')  =  tail{inputs)) 
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ReadlnputChannelAnylnputStructare  will  take  one  step  of  reading  any  input 
structure  of  the  first  cycle  of  input. 

ReadInputChannel  =  ReadNewInputStructurt  v 
ReadDeleielnputStructure  V 
ReadModifyInputStructure  V 
CloseInputChannel 


6.6.7  Finishing,  Stepping  and  Resetting  the  InputCycle 

When  there  are  no  more  input  structures  to  read  on  any  input  channels,  Input- 
CycleFinish  pops  the  inputs  vector  and  moves  the  input  cycle  to  the  finished 
state. 


_ InputCycleFimsh _ 

A 10 

input  _cycle  dilate  =  InputCycleFiniahedState 
—  pte  ReadInputChannel 
inputs’  =  tail[inputs) 

input  ^cycle -.state'  =  InputCycleFxnishedState 

InputCycIeStep  steps  the  input  cycle  using  the  three  operations. 

InputCycleStep  =  StartReadInput  v  ReadInputChannel  v 
InputCycleFinish 

InputCycIeReset  is  specified  to  allow  the  implementation  to  reset  the  oper¬ 
ation  of  the  input  cycle  state  machine  at  any  point  of  execution. 

, _ InputCycIeReset _ 

AIO 

input -Cycle  ..state'  =  InputCyclelnxtialState 
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If  an  OutputLink  of  the  lop  level  state  does  not  have  a  corresponding 
OutputStTucture  in  the  last  CydeOfOutput,  then  SendOutputChannelOutput- 
StTuctureObject  creates  a  new  OutputStructure  with  the  object  of  the  link  and 
adds  it  to  the  output. 

_ SendOutputChannelOu.tpuiStructureObject _ 

I  A/0 

j  output^cyde^atate  =  OutputCydeSendState  =  output  _cyde_staie' 
j  3  i  :  Output  Attribute  • 

j  3  tu  :  WM  I  w.id  =  TopState  A  w. attribute  =  i  A 
1  w .context ^acceptable -preference  =  No  A 

OutputMapping{i)  ^  dom{la3t{outputs))  • 
j  3  05  ;  OutputStructure  \ 

'  OS. object  =  w. value  A  OS.wmea  =  0  • 

(last  (outputs')  =  last(outputs)Q 
{  OutputMapping(i)  — >  05}  A 
front  (outputs')  =  front(outputs)) 


SendOutputChanndOutputStructureWME  finds  any  working  memory  ele¬ 
ments  of  the  transitive  closure  of  an  OutputLink  that  have  not  been  added  to 
their  OutputStructure  and  adds  them  to  the  structure. 

_ SendOutputChannelOutputStructure  WME _ 

I  A/0 

I 

I  output-cyclestate  —  OutputCydeSendState  =  output-cycle  state’ 

I  3  i  :  Output  Attribute  • 

'  3  ui  :  WM  \  w.id  =  TopState  A  w. attribute  =  i  A 

Ml  .context -acceptable -preference  —  No  • 

3  05,  OS'  :  OutputStructure  \ 

OS. object  —  w. value  A  OS'  object  —  w. value  • 

I  3  u/2  :  0^d^rJ^fj^(TCI^rJ^f£(WM)({w.value}),  WM)  i 

W2  ^  OS.wmes  a  OS'.wmes  =  OS.wmea  U  {ti'2}  • 

I  (last(outputs')  =  last  ( outputs  )0 

{OutputMapping(t)  —*  OS'}  A 
I  front(outputs')  =  front(outputs)) 


SendOutputChannel  composes  the  operations  to  send  out  OutputStructures. 

SendOutputChannel  =  SendOutputChannelOutputStructureObject  V 
SendOutputChannelOutputStructure  WME 
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When  there  is  no  more  output  to  send,  OutputCycleFinish  finishes  the  out¬ 
put  cycle. 

I _ OutputCycleFinish - - 


output— cycle  ^state  =  OutputCycleSendState 
pre  SendOutput Channel 

output— cycle— state'  =  OutputCycleFinishedState 
OutputCycIeStep  sequences  all  of  the  operations  of  the  OutputCycle. 
OutputCycleStep  = 

StartSendOutputChannel  v  SendOutputChannel  V 
OutputCycleFinish 

OutputCycleReset  eillows  the  implementation  to  reset  the  OutputCycle  state 
machine  from  any  state  under  exceptional  conditions. 

_ OutputCycleReset - - 

1  A/0 

I  output-cyclestate'  =  OutputCyclelnitialState 
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Chapter  7 

Decide 


The  decision  procedure  reads  preference  memory  to  decide  what  should  be  in 
working  memory,  including  the  context  impasse  stack  and  attribute  impasses. 
Decide’s  specification  is  composed  of  a  state  schema  and  four  state  machines; 
impasser,  preference  semantics,  working  memory  phase  and  quiescence  phase. 
Soar's  top  level  state  machine  steps  decide  through  the  working  memory  phase 
(WMPhase)  or  the  quiescence  phase  (QPhase).  The  working  memory  phase  and 
the  quiescence  phase  step  preference  semantics  to  determine  the  values  of  slots 
and  the  impasser  to  add,  modify  and  remove  goals  and  impasses. 

Z’s  bottom- up  approach  to  specification  requires  that  we  first  specify  the 
state  schema  of  a  sequential  system,  and  then  specify  its  transitions.  Conse¬ 
quently  we  present  the  state  schemas  for  decide’s  four  state  machines  first,  then 
we  present  decide’s  total  state  schema,  and  then  we  present. the  state  transitions 
for  each  of  the  component  state  machines. 

This  chapter  is  organized  into  ten  sections. 

•  Section  7.1  Impasses  —  defines  impasses,  Soar’s  goal  representation. 

•  Section  7.2  Impasser  State  -  defines  the  state  of  the  impasser. 

•  Section  7.3  Preference  Semantics  State  —  defines  the  state  of  preference 
semantics. 

•  Section  7.4  Working  Memory  Phase  State  —  defines  the  state  of  working 
memory  phase. 

•  Section  7.5  Quiescence  Phase  State  —  defines  the  state  of  quiescence 
phase. 

•  Section  7.6  Decide’s  Total  State  —  defines  the  totsd  state  of  decide. 

•  Section  7.7  Impasser  —  defines  the  state  machine  that  implements  im- 
passing. 
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•  Section  7.8  Preference  Semantics  —  defines  the  state  machine  that  imple¬ 
ments  preference  semantics  calculations. 


•  Section  7.9  Working  Memory  Phase  —  defines  the  state  machine  that 
implements  the  working  memory  phase. 

•  Section  7.10  Quiescence  Phase  —  defines  the  state  machine  that  imple¬ 
ments  quiescence  phase. 

7.1  Impasses 

This  section  describes  the  basic  concepts  of  an  impasse,  and  provides  some 
operations  to  help  access  and  modify  the  working  memory  elements  of  impasses. 

The  context  impasse  stack  is  represented  as  elements  in  working  memory, 
and  so  are  its  attribute  impasses.  Each  element  of  a  context  impasse  in  the 
stack  holds  the  context’s  identifier  in  its  id  component,  and  its  attribute  is  an 
element  of  ImpasseAt tribute,  defined  in  Section  5.5.9. 

ImpasseiWMEs  ;  Symbol  x  P  Identifier  x  P  WME  — *  P  WME 

V  5_or_»  :  Symbol;  GM  :  P  Identifier;  WM  :  P  WME  • 

I  Impasses  WMEs{g-or_i,  GM,  WM)  = 

I  {w  :  WM  I  g-or^i  €  GM  A  w.id  =  g~or_i  A 
w.  attribute  €  Impasse  Attribute  A 
I  w  context  ^acceptable  ^preference  =  No} 

There  are  eight  attributes  that  are  used  to  create  working  memory  elements 
defining  a  context  impasse. 

1.  *  PROBLEM-SPACE  '  —  the  optional  problem  space  of  the  subgoal. 

2.  '  STATE  '  —  the  optional  state  of  the  subgoal. 

3.  '  OPERATOR'  —  the  optional  operator  of  the  subgoal. 

4.  'OBJECT'  —  the  parent  context  impasse  for  a  context  impasse,  or  the 
identifier  of  the  impassed  slot  for  an  attribute  impasse. 

5.  *  ATTRIBUTE  '  —  the  attribute  of  the  impassed  slot. 

6.  '  IMPASSE  '  —  the  type  of  impasse  (see  7.2). 

7.  'ITEM'  —  the  candidates  that  were  available  for  decision  for  'TIE', 
'CONFLICT'  or  'CONSTRAINT-FAILURE'  impasse. 

8.  '  CHOICES  '  —  if  there  are  no  '  ITEM  '  augmentations,  an  impasse  has 
a  'CHOICES'  augmentation  of  value  'NONE',  otherwise  its  value  is 
'MULTIPLE'. 
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Decide  uses  only  the  'OBJECT',  'ATTRIBUTE',  'IMPASSE',  'ITEM' 
and  '  CHOICES  '  attributes  for  attribute  impasses.  The  values  from  the 
('  OBJECT  ', '  ATTRIBUTE  ')  working  memory  element  pair  form  the  slot  for 
which  decide  had  incomplete  or  inconsistent  information.  The  '  IMPASSE ' 
element  holds  as  a  value  the  type  of  impasse.  The  'CHOICES'  describes  L’ 
there  were  'MULTIPLE'  or  'NONE'  value  choices  available  to  the  decision 
procedure  for  the  impassed  slot.  Each  choice  is  represented  in  working  memory 
using  an  augmentation  of  attribute  '  ITEM  '. 

The  recursive  function  GoalDescendents  follows  the  chain  of  'OBJECT' 
attributes  backwards  through  working  memory  to  construct  the  set  of  identifiers 
of  the  descendant  goals  of  a  given  goal. 

I  GoalDeacendanis  :  Identifier  x  P  Identifier  x  P  WME  —  P  Identifier 

j  V  j  :  Identifier;  GM  :  P  Identifier;  WM  :  P  WME  • 

I  (3i  c  :  GAf  •  makeWME(c,'  OB2ECT  ‘ ,  g,  No)  6  WM)  => 

!  (3i  c  :  GM  \  makeWME{c, '  OBJECT',  ff.  No)  €  WM  • 

I  GoalDe3cendanta{g,  GM,  WM)  = 

\  {c}  '■-*  GoalDescendants{c,  GM ,  WM))  A 

-  (3i  c  :  GM  •  makeWME(c,'  OhiECT g.  No)  e  WM)  => 

!  GoalDescendants{g ,  GM ,  WM)  —  0 


7.2  Impasser  State 

The  impasser  creates,  modifies  and  deletes  both  context  and  attribute  impasses. 
Its  state  machine  requires  only  three  states  (Figure  7.1): 

1.  an  initial  state  which  is  used  to  optionally  remove  old  impasses 

2.  a  state  from  which  new  impasses  are  created  or  old  impasses  have  their 
items  changed  and 

3.  a  final  state. 


Impasser  State  Impasser  Initials  tate 

ImpasserCreateOrChangeState 
I  Impasser  FinishedState 
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ipasserRemovelmpasse 


The  impasser  is  started  with  a  slot  that  may  need  an  impcisse  created, 
changed  or  removed,  and  the  type  of  the  impasse  that  is  required. 

i  ImpasseType  :  P  Constant 
ImpasseType  = 

{'  CONSTRAINT-FAILURE *  CONFLICT  ' ,  *  TIE ' , 

'  NO-CHANGE '  NONE '} 

There  are  four  types  of  impasses  and  one  symbol  used  to  specify  that  the 
slot  does  not  require  an  impasse. 

1.  'CONSTRAINT-FAILURE'  -  created  when  decide  has  more  than  one 
required  candidate  for  a  slot,  or  has  a  required  candidate  that  is  also 
prohibited. 

2.  '  CONFLICT  '  —  created  when  decide  has  inconsistent  better,  worse,  best 
or  worst  preferences  for  a  slot. 

3  '  TIE  '  —  created  when  decide  has  more  than  one  acceptable,  non-parallel, 
non-indifferent  candidate  for  a  slot. 

4.  'NO-CHANGE*  —  created  when  quiescence  is  reached  and  the  decision 
procedure  has  no  change  that  it  can  make  to  the  context  stack. 

5.  '  NO.NE  '  —  signifies  that  preference  semantics  has  determined  that  it  has 
no  candidate,  or  a  unique  candidate  for  a  slot. 

The  flag,  context_changed,  of  type  ContextChanged  is  used  to  record  if 
the  context  has  been  changed  during  quiescence  phase  or  the  impasser  state 
machine.  This  allows  the  quiescence  phase  to  know  when  the  context  has  been 
changed  so  that  it  can  stop  looping  over  the  slots  of  the  context. 

ContextChanged  Changed  ■  Unchanged 

The  ImpasserStateSchema  groups  the  slot  to  be  impassed,  the  type  of  the 
impasse,  the  items  under  consideration  from  preference  semantics  and  the  state 
counter  for  the  impasse  state  machine 

_ ImpasserStateSchema _ 

impasser ^state  :  ImpasserState 
slot  :  Slot 

impasse  :  ImpasseType 
i  items  ;  P  Symbol 

context  ^changed  :  ContextChanged 
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7.3  Preference  Semantics  State 


Preference  semantics  reads  the  contents  of  preference  memory  to  decide  new 
values  for  working  memory  slots.  The  preference  semantics  state  machine  re¬ 
quires  eleven  states  (Figure  7.3):  nine  to  perform  the  filter-like  operations  to 
decide  slots,  an  initial  and  a  final  state. 

1.  PSInitieJState  —  preference  semantics  starts  out  in  this  state. 

2.  PSRequireState  —  this  state  checks  for  required  candidates  in  preference 
memory  and  also  constraint  failure  impasses  involving  require  preferences. 

3.  PSAcceptableState  —  this  state  collects  the  candidates  that  have  accept¬ 
able  preferences  in  memory. 

4.  PSProhibitState  —  this  state  filters  out  the  candidates  that  have  been 
prohibited. 

5.  PSRejectState  —  this  state  filters  out  the  candidates  that  have  rejects  in 
PM. 

6.  PSBetterWorseState  —  this  state  checks  for  better  worse  conflicts,  and 
otherwise  filters  out  candidates  based  on  better/worse  preferences. 

7.  PSBestState  —  this  state  filters  out  candidates  using  the  best  preferences. 

8.  PSWorstState  —  this  state  filters  out  candidates  using  the  worst  prefer¬ 
ences. 

9.  PSIndifFerentState  —  If  all  of  the  remaining  candidates  are  mutually  in¬ 
different.  this  state  returns  them  as  indifferent.  If  they  are  not,  and  this 
is  a  context  impasse  slot,  a  tie  impasse  is  returned.  Non-context  slots’s 
items  are  tested  to  see  if  they  are  mutually  parallel. 

10.  PSParallelState  —  If  all  of  the  remaining  candidates  are  mutually  paredlel, 
they’re  returned  as  mutually  parallel.  Otherwise,  a  tie  impasse  is  returned. 

11.  PSFinishedState  —  preference  semantics  enters  this  state  when  it  has 
reached  a  conclusion  for  its  slot. 
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PreferenceSemanticsStaie 


PSImtialState 

PSRequireState 

PSAcceptableState 

PSProhibilSiate 

PSRejectState 

PSBetierWorseStaie 

PSBestState 

PSWorsiState 

PSlndifferentState 

PSParallelState 

PSFtnishedState 


Preference  semantics  requires  an  input  slot,  and  produces  an  impasse,  a  pos¬ 
sibly  empty  set  of  conflicting,  indifferent  or  parallel  items  and  a  flag,  number_o£.winners 
of  type  NumberOfWinners.  The  number_of_winners  flag  is  set  whenever  there 
is  a  winning  value,  e.g.,  there  is  not  an  impasse.  If  a  single  winner  is  chosen  or 
there  are  a  set  of  mututilly  indifferent  winners.  number_of_winners  is  One.  If  all 
of  the  winners  are  mutually  parallel,  then  number_o£_winners  is  All.  This  allows 
WMPhase  to  distinguish  a  set  of  mutually  parallel  candidates  that  should  all 
be  installed  in  working  memory  from  a  set  of  mutually  indifferent  candidates 
that  should  have  only  one  value  installed  or  maintained. 


NumberOfWinners  ::=  All  !  One 

The  PreferenceSemantJcsStateSchema  schema  groups  preference  semantics's 
inputs,  outputs  and  state  counter. 

_ PreferenceSemanticsStateSckema _ 

I  ps^state  :  PreferenceSemanticsStaie 
I  slot  :  Slot 

items  :  P  Symbol 

impasse  :  ImpasseType 

number ^of -winners  :  NumberOfWinners 


7.4  Working  Memory  Phase  State 

The  WMPhase  state  machine  is  implemented  in  six  states  (Figure  7.3). 

1.  WMPhaselnitiaJState  —  the  state  machine  starts  out  in  this  state. 

2.  WMPhasePickSlotState  —  this  state  picks  any  non-context  slot  with  changed 
preferences  for  decision. 
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WMPhaseStepDecideSlot 


WMPhase 

Stepimpasser 


WMPhase 

AddWME 


WMPhase 

RemoveWME 


Figure  7.3:  Working  Memory  Pheise  State  Machine 
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3.  WMPhaseDecideSIotSt&te  —  this  state  steps  the  preference  semantics 
state  machine  until  it  has  arrived  at  a  decision. 

4.  WMPhaseImpasseState  —  if  the  decision  is  an  impasse,  this  state  steps 
the  impasse  machine  untU  is  has  added,  changed  or  removed  the  impasse. 

5.  WMPhaseChangeWMState  —  this  state  adds  or  removes  the  WMEs  for 
the  slot. 

6.  WMPhaseFinishedState  —  the  state  machine  finishes  in  this  state. 


WMPhaseState  WMPhaselnitialState 
\  WMPhasePickSlotState 
i  WMPhaaeDecideSlotState 
WMPhaaelmpasserState 
WMPhaseChange  WM State 
WMPhaseFinishedState 

The  preference  phase  records  the  set  of  slots  that  have  preferences  added  or 
retracted  in  the  ChangedSIots  component  of  the  WMPhaseStateSchema.  The 
WMPhase  destructively  iterates  the  component  sJot  over  the  changed  slots,  runs 
the  decision  procedure  on  the  slot  and  receives  back  information  in  the  hems, 
impasse  and  the  number_o£.winners  components. 

_ WMPhaseStateSchema _ 

!  wmphase^state  :  WMPhaseState 
changed-slots  :  P  Slot 
'  slot  :  Slot 
'  items  :  P  Symbol 
i  impasse  :  ImpasseType 
\  number _of_winners  :  NumberOfWinners 


7.5  Quiescence  Phase  State 

Quiescence  Phase’s  state  machine  requires  six  states  (Figure  7.4). 

1.  QPhaselnitialState  —  the  state  machine  starts  from  this  state. 

2.  QPhasePickSlotState  —  chooses  the  context  impasses  and  which  one  of 
its  slots  to  decide  next. 

3.  QPhaseDecideSlotState  —  this  state  steps  the  preference  semantics  state 
machme  given  this  slot  as  an  argument. 
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QPhaseStepDecideSlot 


QPhaseChanged 
eferencesNoChange 
Impasse 


QPhaseRemove 

WME 


QPhaseAdd 

WME 


Figure  7  4:  Quiescence  Phase  State  Machine 
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4.  QPhaseImpasseiState  —  this  state  steps  the  impasser  given  the  result  of 
preference  semantics. 

5.  QPhaseChangeWMState  —  this  state  changes  the  values  in  working  mem¬ 
ory  for  the  slot. 

6.  QPhaseFinishedState  —  the  final  state  of  the  machine. 


QPhaaeState  ;:=  QPhaselnitialState 
I  Q  Phase  PickSloiState 
I  QPhaseDecideSlotSlaie 
1  QPhaselmpasserState 
I  QPhaseChange  WMStaie 
I  QPhaseFinishedState 

The  set  Con textSht Attribute  holds  the  attributes  for  context  slots. 

ContextSlot Attribute  :  P  ImpasseAttribute 
ContextSlot  Attribute  = 

{ '  PROBLEM-SPACE  ' ,  *  STATE  ' , '  OPERATOR ' } 

The  QPhase  state  machine  uses  six  pieces  of  state; 

1.  a  state  counter,  qphasestate 

2.  the  slot  of  the  context  under  consideration 

3.  a  flag  that  marks  if  the  context  has  been  changed 

4.  the  set  of  slots  that  preference  phase  has  changed  preferences  for 

5.  the  set  of  items  that  the  preference  semantics  returned  and 

6.  the  number  of  winners  amongst  those  items. 


_ QPhaseStateSchema _ 

qphasestate  ;  QPhaseState 
slot  :  Slot 

context  ^changed  :  Context  Changed 
changed  ^slots  ;  P  Slot 
items  :  P  Symbol 

number ^of  ^winners  :  Number OfWinners 
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7.6 


Decide’s  Total  State 


The  decide  state  schema  includes  the  state  schemas  for  its  state  machines,  de¬ 
fines  the  impasse  memory,  the  goal  memory  and  two  pointers  into  it,  and  shares 
the  temporary  memory,  ..s  component  memories  and  the  identifier  table  with 
the  other  major  modules  of  Soar. 

The  goal  memory,  GM,  and  impasse  memory,  IM,  are  defined  as  sets  of 
identifiers.  All  information  about  the  type  of  context  impasse  or  attribute  im¬ 
passe  is  represented  by  working  memory  elements.  The  goal  memory  is  also 
constrained  to  be  contained  within  the  transitive  closure  of  the  bottom  goal. 
Impasse  memory  is  constrained  somewhat  differently:  all  of  the  objects  of  the 
attribute  impasses  must  be  connected  to  the  bottom  goal. 

Temporary  memory,  TM,  is  defined  and  constrained  by  three  recursive  ax¬ 
ioms. 

1.  Temporary  memory  is  the  union  of  the  temporary  memory  elements  cre¬ 
ated  from  all  of  working  memory  and  production  memory,  using  the  free 
type  constructors  for  temporary  memory  elements. 

2.  Temporary  memory  is  defined  to  be  transitively  closed  from  the  bottom 
goal  and  the  impasses.  This  means  that  all  elements  are  on  a  path  that 
starts  with  the  identifier  of  the  bottom  goal  or  an  impasse  identifier. 

3.  Working  memory,  which  may  be  viewed  cis  a  part  of  temporary  memory, 
contains  a  working  memory  element  of  context_acceptable_preference  Yes 
if  and  only  if  there  is  a  corresponding  acceptable  preference  for  that  con¬ 
text  slot.  The  mapping  ContextlmpassePTcferences  is  used  to  construct 
the  set  of  working  memory  elements  that  correspond  to  the  context  ac¬ 
ceptable  preferences. 


I  ContextlmpassePreferences  :  P  Identifier  x  P  Preference  — *  P  WME 

V  GM  :  P  Identifier',  PM  :  P  P'reference  • 
ContextImpassePreferences{GM ,  PM)  = 

{p  :  UnaryP''  ^PM  O  ran  UnaryP^  ] 

p  .id  €  GM  A  [p. preference  =  '  -t-  ’  V  p. preference  =  ' !  ’)  A 
p. attribute  6 

{*  PROBLEM-SPACE ',  *  STATE  ', '  OPERATOR '} 

•  make  WME{p -id,  p .attribute,  p .value,  Fes)} 
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, _ Decide _ 

IM  :  P  Identifier 
GM  :  P  Identifier 
bottom^goal,  top-goal  :  Identifier 
IdentifierTable  :  P  Identifier 
j  TM  :P  TME 
\  WM  :  P  WME 
\  PM  :  P  Preference 

PreferenceSemanticsStateSchema 
Impasser  states  chema 
1  WMPhaseStateSchema 
QPhaaeStateSchema 

j  TM  =  PreferenceTME\PM\  U  WMETME\  WM\ 

TM  =■  Ond'j'j^£’[(TCI'pj^£{TM))({bottom—goal}  L  IM),  TM] 

I  ContextImpassePreferencea{GM ,  PM)  = 

{w  :  H^A/  w .context -acceptable -preference  =  y’es} 

IM  =  {i  :  IM 

5  0  :  Symbol  • 

i  WMETME{makeWME{t, '  OBJECT o,  No))  6 
I  Ondj‘j^f£{{TCIj'j^£{TM))({bottom-goal}'<.^IM),  TM)} 

GM  =  i(TCIjj^£{TM)){{bottom-goal}))  ^  GM 

Decide  starts  off  with  its  four  state  machines  in  their  finished  state,  and 
empty  impasse  and  goal  memories. 

_ InitDecide _ 

Decide 

ps-state  =  PSFinishedState 
impasser  state  —  Impasser FinishedState 
I  wmphasestate  =  WMPhaseFinishedState 
!  qphase  state  =  QPhaseFinishedState 
IM  =  Z 
GA/  =  {} 
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The  top  level  state  machine  initializes  decide  with  the  DecideCieateFirstGoal 
operation.  It  sets  goal  memory  to  a  singleton,  adds  the  object  working  memory 
element  for  this  goal  and  its  type  working  memory  element,  and  sets  the  top 
and  bottom  goal  pointers  to  the  single  gocil. 

_ DecideCreateFiratGoal _ 

A  Decide 

[  3  g  :  Identifier  \  IdentifierTable  •  (GM  =  {j}  A 
top^goal  =  g  A 
bottom^goai  =  g  A 

WM'  =  {make  WME  {g,' OBJECT No), 
makeWME(g,' TY?E\' GOAL',  No)}) 

ps-staie  =  PSFinishedState 

impaaser^state  =  ImpasserFinishedState 

wmphase  state  =  WMPhaaeFinishedState 

qphase  state  =  QPhaseFimshedState 

IM  =  0 


7.7  Impasser  Transitions 

The  impasser  has  six  state  transitions  between  its  three  states  (Figure  7.1). 

1.  Impasserinitialize  —  used  to  initialize  the  state  machine. 

2.  ImpasserNoImpasseToRemove  —  If  there  is  no  need  to  remove  an  impasse, 
this  transits  the  machine  from  the  initial  state  to  the  CreateOrChange 
state. 

3.  ImpasserRemoveImpasse  —  If  there  is  an  old  impasse  in  memory  that  is 
for  the  wrong  type  of  impasse  or  the  wrong  slot,  this  transition  removes 
it. 

4.  ImpasserCreateImpasse  —  If  preference  semantics  has  determined  a  need 
for  an  impasse  that  is  not  yet  in  memory,  this  creates  it. 

5.  ImpasserChangeImpasse  —  If  preference  semantics  has  found  a  changed 

set  of  items  for  an  existing  *  TIE  '  CONFLICT  '  or  ‘  CONSTRAINT-FAILURE  ' 
impasse,  this  transition  changes  the  items  set. 

6.  ImpasserNoNewImpasseOrChanges  —  If  there  is  not  a  new  impasse  and 
no  changes  to  an  item  set.  this  finishes  the  state  machine’s  execution. 


151 


Im passer  Initialise  readies  the  imptisser  to  run  by  moving  it  from  the  final  to 
the  initial  state. 

_ Impasser  Initialize _ 

ADecide 

context -changed'  =  Unchanged 
impasser  state'  =  ImpasserlnitialSlate 


The  impasser  first  checks  for  an  old  impeisse  existing  in  memory  that  must 
be  removed.  An  impasse  must  be  removed  if  preference  semantics  has  decided 
that  the  slot  needs  a  different  type  of  impasse,  a  higher  slot  in  the  context  has 
an  impasse,  or  the  slot  should  have  no  impasse  at  all.  ImpassetRemovelmpasse 
is  designed  to  remove  both  context  and  non-context  impasses,  so  it  searches 
for  an  impasse  identifier  in  IM  or  GM.  If  the  obsolete  impasse  is  a  non-context 
impasse,  it  deletes  it  from  IM.  If  the  obsolete  impasse  is  a  context  impasse,  it 
deletes  it  and  its  descendants  from  GM,  and  updates  the  pointer  to  the  bottom 
of  the  context  stack. 

_ Impasser  Removeimpasse _ 

ADecide 

impasser  state  =  ImpasserlnitialState 
5  t  :  IM  u  GM  ! 

makeWME(i,'  OBJECT' ,first(slot),  No)  €  WM  • 

-  ({makeWME{i, '  ATTRIBUTE ',  second(slot),  No)  6  WM)  a 
(make IUM£’(t,  *  IMPASSE ',  imposae,  TVo)  €  WM)) 

((«  €  IM  => 

IM'  =  /M\{i}  A 

WM'  =  WM  \  Impasses  WMEs {i,  IM <  WM))  A 
(»  €  GM  => 

(context-changed'  =  Changed  A 

(GM'  =  GM  \  ({i}  U  GoalDescendants{i,  GM ,  W'M)))  A 
(bottom-goal'  —  first(slot)))  A 
(  WM'  =  WM  \  ImpassesWMEs(i,  GM,  WM) 

\(U{ff  :  GoalDescendants(i,  GM ,  WM)  • 

ImpassesWMEs(g,  GM ,  lUM)})))) 

1  impasser  state'  =  ImpasserCreateOrChangeState 
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If  the  impasse  in  memory  is  the  desired  type  of  impasse  or  there  is  no  im¬ 
passe  in  memory  then  ImpasserNoImpasseToRemove  moves  the  impasser  into 
the  create  or  change  state. 

_ ImpasserNoImpasse  ToRemove _ 

ADecide 

impasser  state  —  Impasser  InitialState 
3 »  :  IM  U  GM  • 

{makeWME(i,'  OBJECT\first(slot),  No)  e  WM  A 
makeWME{i, '  ATTRIBUTE  second  (slot),  No)  £  WM  A 
mate IUAf£'(t, '  IMPASSE impoise,  JVo)  €  WM)  V 
(5  i  :  IM  u  GM  • 

{makeWME{i, '  OBJECT  No)  e  WM  A 

makeWME{i, '  ATTRIBUTE  second{slot),  No)  €  WM)) 

i 

j  impasser  state’  —  ImpasserCreateOrChangeState 
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If  the  desired  impasse  is  not  in  memory,  ImpasserCreateImpasse  selects  an 
identifier  that  is  not  in  the  IdentifierTabJe,  and  consequently  not  in  use  by 
the  system,  and  adds  the  identifier  to  IM  or  GM  and  the  basic  three  elements 
required  for  the  impasse.  If  the  impasse  is  a  'CONSTRAINT-FAILURE'  or 
a  '  NO-CHANGE  '  then  an  element  of  attribute  '  CHOICES  '  value  '  NONE  ' 
is  also  added.  If  the  impasse  is  a  'CONFLICT'  or  a  'TIE'  then  an  element 
of  attribute  '  CHOICES  '  value  '  MULTIPLE '  is  added  instead.  An  element  of 
attribute  '  ITEM  '  is  added  for  each  candidate  returned  by  preference  semantics 
in  the  items  set.  Chunking's  Traceltems  operation  is  referenced  to  give  the  new 
item  elements  numbers  and  setup  their  working  memory  traces  to  point  to  the 
preferences  that  caused  them  to  be  considered  for  the  slot. 

_ ImpaaaerCreaielmpasse _ 

I  ADecide 

!  impaaaer^state  =  ImpaaaerCreateOrChangeState 
I  -  (3  1  :  /M  u  GAT  • 

makeWME {i,'  OBJECT ' ,firat(alot),  No)  i  WM  a 
makeWME{i, '  ATTRIBUTE  ',  second (s/ot).  No)  e  WM) 

3  1  ;  Identifier  I  i  ^  Identifier  Table  • 
j  (firat(alot)  €  GM  A 

j  aecond{alot)  €  ContextSlot Attribute  u  {'  GOAL  '})  =s> 

{GM' =  GM  u  {%}  A 
'  context -changed'  =  Changed  A 

j  bottom-goal'  =  t)  A 

•  -■  {firat{alot)  £  GM  A 

;  aecond(alot)  £  ContextSlot  Attribute  U  {'  GOAL  '})  => 
i  IM'  =  IM\^{i}A 

1  3  H"  ;  P  WME  I  lA'  =  {r  :  itema  •  makeWME{x,  '  ITEM  ',  v,  No)} 

WM'  -  WM^ 

{makeWME{i, '  OBJECT  ' ,  first{slot),  No), 
makeWME{i, '  ATTRIBUTE  ',  aecond(alot),  No), 
makeWME(i, '  IMPASSE  ',  impaaae,  No)}u 
{ui  :  WME  \  w  =  makeWME(i, '  CHOICES  ', '  NONE  ',  No)  a 
I  jmposse  €  {' CONSTRAINT-FAILURE NO-CHANGE '}}l. 

I  {w  :  WME  w  =  makeWME{i, '  CHOICES  ', '  MULTIPLE  ',  No)  a 

j  tmpaaae  £  {' CONFLICT ',' TIE '}}  u  W  A 

Traceltema 

!  impaaaer -atate'  =  ImpaaaerFxniahedState 
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If  the  correct  type  of  impasse  for  the  slot  exists  in  memory,  but  its  set 
of  items  is  now  different,  Ch an gelm passe  removes  the  elements  for  the  items 
that  are  no  longer  involved  in  the  impasse,  and  adds  in  elements  for  the  new 
items.  This  does  not  change  the  main  structure  of  the  context  stack,  only  its 
items,  so  the  context_changed  flag  is  not  set  and  sub-slots  and  sub-goals  are 
not  flushed.  Having  updated  working  memory  to  match  preference  semantic's 
required  impasse,  the  Changelmpasse  steps  to  the  finished  impasser  state. 

_ ImpasserChangelmpasse _ 

^Decide 

I  impasser  _state  =  ImpasserCreateOrChangeState 

i 

1  3i  :  IM  O  GM  \ 

j  makeWME {i,' OBJECT  ‘ ,  fir st{ slot),  No)  €  WM  A 

makeWME{t,'  ATTRIBUTE' ,  second(slot),  No)  G  WM  A 
makeWME {i, '  IMPASSE  impasse,  No)  G  WM  A 
Items  ^  {d  :  Symbol  1  makeWME{i, '  ITEM  v,No)  G  WM}  • 
3W  ■.?  WME 

W  =  {u)  :  WM  \ 

I  3  r  :  Symbol  \  items  *11;=:  makeWME(i, '  ITEM  v,  No)} 

u{t)  :  items  |  makeWME{i, '  ITEM  ',  v.  No)  ^  WM  • 
makeWME(i,'lTEM',v,No)}  • 

I  WM'  =  WM  \  W  A  Trace  Items 

impasser^state'  =  ImpasserFinishedState 


If  there  is  no  need  for  a  new  imptisse,  or  the  impasse  in  memory  is  exactly 
right,  then  ImpasseiNoNewl  npasseOr Changes  completes  the  impeisser’s  run. 

_ Impasser  NoNewImpasseOrChanges _ 

A  Decide 

! _ 

impasser  _state  =  ImpasserCreateOrChangeState 

I  impasse  =  '  NONE  '  v 
,  {3i  :  IMu  GM  • 

'  makeWME{i,' OBJECT '  ,first{slot).  No)  G  WM  A 

make  W^A/£’(i.  '  ATTRIBUTE  *.  secoT»d(slot), -Vo)  “  WM  A 
\  make  WME{i, '  IMPASSE  impasse,  No)  G  WM  A 

items  =  {v  :  Symbol  '  makeWME{i. '  ITEM  v,  No)  G  WM}) 

• 

impasser  ,  state'  =  ImpasserFinishedState 
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After  initialization  ImpasserStep  will  drive  the  impasser  state  machine  through 
all  of  its  states  to  completion. 

ImpasserStep  =  ImpasserNolmpasaeToRemove  v  Impasser  Remove  Impasse  v 
ImpasserCreaieImpasse  \  ImpasserChangeImpasse  v 
Impasser  NoNewImpasseOrChanges 


7.8  Preference  Semantics  Transitions 

Preference  Semantics  is  defined  in  seventeen  transitions  (Figure  7.3):  one  to 
initialize,  fifteen  for  processing  the  filter-like  actions  and  one  that  is  a  concession 
to  the  obvious  implementation  to  allow  a  fast  exit  from  the  state  machine  in  a 
common  case. 

The  PSlnitialize  initializes  the  state  counter,  empties  the  set  of  candidate 
items,  and  sets  the  impasse  to  '  NONE 

_ PSlnitialize _ 

^Decide 

ps^siate'  =  PS  Initials  tale 
items'  =  0 
impasse'  =  '  NONE  ' 

StartPS  moves  the  state  machine  into  the  state  to  test  for  require  preferences. 

_ PSStart _ 

ADecide 

ps^state  =  P  S  Initials  tate 
slot'  —  slot 

ps-state'  =  PS  Require  State 
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If  there  is  exactly  one  require  preference  for  the  slot  in  memory  and  there  is 
no  prohibit  preference  for  it  in  preference  memory,  then  its  value  is  the  winner. 
The  impasse  is  marked  as  '  NONE the  value  is  returned  in  the  singleton  items 
set,  and  preference  semantics  is  finished. 

, _ PSOneRequire _ 

I  ABecide 

ps^state  =  PS  Require  State 
(3j  V  :  Symbol  • 

makeUnaryPreference{first{3lot) ,  3econd(slot),  v,  ' ! ')  G  PM)  A 
(3  «  :  Symbol  • 

makeUnaryPreference{fi.r»t{slot),  second(slot),v G  PM  A 
makeUnaryPreference{first{3lot),  3econd{3lot),  v,'  ~  ')  G  PM) 

3^  «  :  Symbol  \ 

make UnaT~yPrefereTice(fir3t(slot) .  3ecoTid{3lot).  w,  ' ! ')  G  PM  • 
items'  =  {u} 

impasse'  =  '  NONE  ' 

number  ^of  ^winners'  =  One 

I  ps-state'  =  PSFinishedState 

If  there  is  more  than  one  required  candidate,  then  a  constraint  failure  impasse 
is  recognized  with  all  of  the  required  items  in  the  items  set,  and  preference 
semantics  is  complete. 

, _ PSMuitipleRequires _ 

ABecide 

\ - 

ps-state  =  PSRequireState 

3  V  :  P  Symbol 
j  (  F  =  { t;  ;  Symbol  [ 

j  makeUna7~yPreference(fi.rst{slot),  second{slot),  v,  ' ! ')  G  PM)  A 

I  #V>1)# 

j  items'  =  V 

I  impasse'  =  '  CONSTRAINT-FAILURE  ' 
ps-state'  =  PSFinishedState 
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If  there  exists  a  required  value  that  is  also  prohibited,  a  constraint  impasse 
with  the  required/prohibited  value  is  recognised  and  preference  semantics  ter¬ 
minates. 

_ PS  Require  Prohibited _ 

^Decide 

!  ps^state  =  PSRequireStaie 
\  r  tj  :  Symbol 

I  make  Unary  Preference{first{slot),  second{slot),  v,  ‘ ! ')  G  PM  A 

j  makeUnaryPreference(fi.r»t(slot),  second(slot),  v,  '  ~  £  PM  • 

I  items'  =  {u} 

j  impasse'  =  “  CONSTRAINT-FAILURE  ' 
j  ps^state'  =  PSFinishedState 


If  there  are  no  require  preferences,  preference  semantics  continues  on  to 
consider  acceptable  preferences. 

_ PSNoRequires _ 

ADecide 

ps^state  =  PSRequireState 

I 

-  (5  t’  :  Symbol  • 

makeUnaryPreference{first(slot),  second{slot),  f,  ' ! ')  G  PM) 

!  impasse'  =  *  NONE  ' 

I  items'  =  0 

ps^state'  =  PSAcceptableState 

The  require  processing  is  stepped  through  by  the  Require  transition.  The 
PSRequiie  compound  transition  is  defined  to  allow  users  a  single  place  to  hook 
till  possible  ways  that  preference  semantics  processes  requires. 

PSRequire  =  PSOneRequire  v  PSMultipleRequires  V 
PSRequireProhibited  v  PSNoRequires 
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The  PSAcceptable  transition  collects  all  candidates  with  acceptable  prefer¬ 
ences  in  preference  memory,  stores  them  in  the  items  set  and  moves  the  machine 
to  the  state  that  checks  for  prohibit  preferences. 

I _ PSAcceptable _ 

I  \  Decide 

I  ps^staie  =  PS  Acceptable  State 
j  3v:  Symbol  • 

makeUnaryPreference{firat{slot),  second{slot),  v,'  -r  ')  €  PM 
slot'  =  slot 

items'  =  {«  :  Symbol  \ 

make  Unary  Preference{first(slot),  second{slot),  v,'  +  ')  £  PM} 

I  impasse'  =  *  NONE  ' 

I  ps^state'  =  PSProhibitState 

The  PSNoAcceptable  transition  causes  preference  semantics  to  exit  with  an 
empty  items  set  when  there  are  no  acceptable  preferences  in  memory  for  the 
slot.  This  transition  is  a  compromise  to  the  obvious  implementation.  Preference 
semantics  would  run  exactly  the  same  without  it,  but  one  of  the  common  cases 
is  re-deciding  a  slot  that  has  had  all  of  its  acceptable  preferences  withdrawn  and 
so  every  implementation  would  benefit  from  optimizing  this  case. 

_ PSNoAcceptable _ 

j  ^Decide 

j  ps-state  =  PSAcceptableState 
I  -(dr:  Symbol  • 

make UnaryPreference{first{slot) ,  second(slot).  v,  '  +  ')  £  PM) 
slot'  —  slot 
items'  =  0 

impasse'  =  *  NONE  ' 

I 

j  ps^state'  —  PSFinishedState 
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The  PSProhibst  transition  filters  out  of  the  current  set  of  candidates  those 
which  have  prohibit  preferences,  and  moves  the  machine  to  a  state  that  searches 
for  reject  preferences. 

. _ PSProhibit _ 

I  ADecide 

I - 

I  ps-state  =  PSProhibitState 

I 

!  slot'  =  slot 

j  items'  =  {«  :  items  I 

makeUnaryPTeference{first(slot),  second(slot),  v,  '  '  ^  PM} 

impasse'  =  '  NONE  ' 
ps-state'  =  PSRejectState 

The  PSReject  transition  filters  out  of  the  set  of  items  those  that  have  reject 
preferences,  and  jumps  to  processing  the  better  worse  preferences. 

_ PSReject _ 

^Decide 

I  ps^state  =  PSRejectState 

! 

j  slot'  =  slat 

items'  =  {v  :  items 

make  UnaryPre/erence(first(slot),  second  (slot),  v,  '  —  i  PM} 
impasse'  =  '  NONE  ' 
ps^state'  =  PSBetierWorseStaie 
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The  function  Confljct  is  used  to  extract  the  candidates  that  have  conflicting 
better/ worse  preferences. 

j  Conflict  :  P  Preference  x  Slot  x  P  Symbol  — >  P  Symbol 

I - 

V  PM  :  P  Preference-  slot  :  Slot-,  V  :  P  Symbol  • 

;  Conflict{PM ,  slot,  V) — 

I  {j  :  F  !3fc  :  V  fc. 

(makeBtnaryPreference{first{slot),  second{slot),j,  '  >  ' ,  k)  £  PM  A 
[  makeBinaryPreference{fir$t{slot),  second(slot),  k,  '  >  '  ,j)  £  PM)  V 

(makeBinaryPreference{flrst[slot),  second(slot) ,  j ,  '  ,  k)  £  PM  A 

i  makeBvnaryPreference{first{slot),  second{slot),  k,'  <'  ,j)  £  PM)  V 

j  [makeBinaryPreference{first[slot),  second(slot),j ,  '  >  ' ,  k)  £  PM  A 

I  makeBtnaryPreference{first[slot),  second(slot),  j ,  '  <'  ,k)  £  PM)} 

If  there  are  no  conflicting  better/worse  preferences  between  the  items,  then 
PSNoBetterWorseConflict  applies.  It  filters  out  of  the  items  set  the  ones  that 
have  another  item  that  is  better,  or  are  worse  than  another  item.  The  state 
machine  moves  on  to  filter  by  best/ worst  preferences. 

_ PSNoBetterWorseConflict _ 

^Decide 

ps-state  =  PSBetterWorseState 
slot'  =  slot 

Conflict{PM ,  slot,  items)  =  a 

items'  =■  {v  items  \ 

I  (5  U)  :  items  •  u  A 

makeBinaryPreference{first{slot),  second{slot),  v,'  <’  ,w)  £  PM  A 
makeBinaryPreference(first(slot),  second(slot),  uj,  '  ,v)  £  P^I)} 

impasse'  =  '  NONE  ' 

ps-state'  —  PSBestState 
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If  there  are  better/worse  conflicts,  this  transition  sets  the  items  augmenta¬ 
tion  to  the  a.'  of  the  items  involved  in  the  conflicts,  declares  the  impasse  to  be 
a  conflict  and  finishes  preference  semantics. 

_ P  SBetterWorseConfiict - 

^Decide 

ps  state  =  PSBetterWorseState 
slot'  =  slot 

Confiict{PM ,  slot,  items)  0 
impasse  =  '  CONFLICT  * 
items'  —  C on flict {P M ,  slot,  items) 
psstate'  =  PS  Finis  hedState 

The  processing  of  better /worse  preferences  occurs  in  either  the  PSNoBet- 
terWorseConfiict  or  the  PSBetteiWorseConBict  transitions  and  is  stepped  by 
BetlerWorse. 

PSBetter Worse  =  PSNoBetterWorseConflict  V  P SBetterWorseConfiict 

The  PSBest  transition  filters  the  candidates  for  those  that  have  a  best  pref¬ 
erence  in  memory.  If  there  are  no  best  preferences  in  memory  for  any  of  the 
current  candidates,  the  entire  old  set  of  candidates  is  passed  on.  After  best 
candidate  filtering,  preference  semantics' uses  the  worst  preferences  as  a  filter. 

^PSBest - - — - — — 

'  ^Decide 

I  psstate  =  PSBestState 
slot'  =  slot 

5  F  :  P  Symbol  \ 

V  =  {v  :  items  ' 

makeUnaryPreference(first{slot),  second{slot),  v,'  >')  €  PM}  • 

(V  ^  0  ^  items'  =  V  A. 

V  =  0  =>  items'  =  items) 

j  impasse'  =  *  NONE  ' 

i  psstate'  =  PSWorstState 
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The  PSWorst  filter  removes  the  items  that  have  worst  preferences  in  memory. 

If  they  all  have  worst  preferences  then  none  are  filtered.  After  worst  processing, 
preference  semantics  studies  the  indifferent  preferences. 

. _ PSWorst _ 

i  A  Decide 

\  ps^state  =  PSWorstState 

I  slot'  =  slot 

\  3  I’  :  P  Symbol  | 

I  V  =  {v  :  items  \ 

i  makeUnaryPreference(first{slot),  second{slot),  ti,  '  <  ')  ^  PM}  • 

i  ( F  0  =>  items'  =  F  A 

j  F  =  0  items'  —  items) 

impasse'  =  '  NONE  ' 

ps-state'  =  PSlndifferentState 

The  predicate  AUMutuaMylndifferent  checks  that  all  of  the  candidates  in  the 
set  are  mutueilly  indifferent.  A  candidate  is  mutually  indifferent  with  the  other 
candidates  if  it  is  unarily  indifferent,  or  if  there  is  a  binary  indifferent  preference 
between  the  two  candidates. 

AllMutually Indifferent^  :  P(P  Preference  x  Slot  x  P  Symbol) 

V  PM  :  P  Preference-,  slot  :  Slot-,  F  :  ''  Symbol  • 

AllMutxiallyIndifferent{PM,  slot,  V  j  o 
(Vj,k:  V.^k. 

{make Unary Preference{first{slot),  second[slot), ] ,  =p  )  £  PM  v 
{{makeBinaryPreference{first{slot),second{slot),j,  '=p'.k)  £  PM)  V 
makeBinaryPreference{first{slot).  second{slot).  k,  '  —p  £  PM))) 
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If  the  candidates  are  cdl  mutually  indifferent,  preference  semantics  returns 
with  all  of  the  candidates  in  the  items  set,  an  impasse  of  ‘  NONE '  and  sets  the 
number  of  winners  to  one.  This  allows  WMPhase  and  QPhase  to  tell  that  it 
has  a  set  of  indifferent  candidates  to  choose  one  from. 

_ PS  Mutually  Indifferent _ 

^Decide 

ps-state  =  PSIndifferentState 
slot'  =  slot 
impasse  =  '  NONE  ' 

AllMutuallyIndifferent{PM ,  slot,  items) 
items'  =  items 

I  ps-state'  =  PSFinishedState 

j 

I  number  _of  ^winners'  =  One 

If  the  candidates  are  not  mutually  indifferent  and  the  decision  is  not  for  a 
context  slot,  there  is  still  a  chance  that  all  of  the  items  are  parallel.  In  this  case. 
PSNotMutu&UyIndiffetentNonContextSlot  passes  the  items  on  to  the  parallel 
checking  state. 

_ PSNotMutuallyIndifferentNonContextSlot _ 

j  ^Decide _ 

j  ps -State  =  PSIndifferentState 

j  slot'  —  slot 

impasse  =  "  NONE  ' 

[  ^  AllMutuallyIndifferent{PM ,  slot,  items) 

-•  {first(slot)  t  GM  A 

second{siot)  €  {'  PROBLEM-SPACE  ',  ‘  STATE  *  OPERATOR  '}) 
items'  =  items 
ps -State'  =  PSParallelState 
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Soar6  does  not  support  parallel  candidates  for  context  items,  although  an 
earlier  version  of  Soar  did  for  operators.  So  non-mutually  indifferent  items  for 
context  slots  generate  a  tie,  with  all  of  the  candidates  as  items,  not  just  those 
that  are  not  mutually  indifferent. 

I _ PSNotMutuallyIndifferentConiextSlot _ 

I  ADecide 

ps-state  =  PSIndiff events  tale 
slot'  =  slot 
impasse  =  '  NONE  ' 

-1  AllMutuallyIndifferent(PM ,  slot,  items) 
first  (slot)  E  GM  A 

I  second{slot)  €  {*  PROBLEM-SPACE ‘  STATE ‘  OPERATOR '} 
items'  =  items 

1 

ps-state'  =  PSFinishedState 

I 

j  impasse'  =  '  TIE  ' 


The  complete  indifference  processing  is  handled  by  one  of  the  three  transi¬ 
tions  above,  and  stepped  and  hooked  using  the  Indifferent  transition. 

PSIndifferent  =  PS  Mutually  Indifferent  V 

PSNotMutuallyIndifferentNonContextSlot  V 
P  SNotMutuallyIndifferentConlextSlot 

The  paredlel  state  uses  the  predicate  AUMutuaByPaTallel  to  check  if  the  set 
of  candidates  are  all  mutually  parallel.  An  item  is  mutually  parallel  to  the  set 
of  other  items  if  it  has  a  unary  parallel  preference,  or  if  it  has  either  of  the  two 
possible  relative  parallels  between  each  item. 

I  AllMutually Parallel-  :  P(P  Preference  x  Slot  x  P  Symbol) 

i 

j  V  PM  :  P  Preference',  slot  :  Slot:  V  :  P  Symbol  • 

j  AllMutuallyParallel{PM ,  slot,  V) 

(V  j,  k  :  F  \j:£k» 

(makeUnaryPreference{first{slot),  second{slot),] ,  '&')  £  PM  v 
makeBinaryPreference{fir3t{slot),  second(slot),  '  ic' ,  k)  £  PM  v 

I  make  Binary  Preference(first(slot),  second(slot),  k,'  ,j)  £  PM)) 
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If  all  of  the  candidates  are  mutually  parallel  PSMutuaJlyPaTaliel  returns  all 
of  the  items,  sets  impasse  to  '  NONE'  and  the  number  of  winners  to  All. 

_ PS  Mutually  Parallel _ 

I  ^Decide 

ps^state  =  PSParallelState 
j  slot'  =  slot 

I  AllMutuallyParallel(PM ,  slot,  items) 

i  . 

items  =  items 

j 

impasse'  =  '  NONE  ' 
j  number  ^of  ^winners'  =  All 
ps^state'  =  PSFinishedState 


PSNotMutuallyPaiaHeJ  returns  a  tie  .impasse  if  all  of  the  candidates  are  not 
mutually  parallel. 

, _ PSNotMutually  Parallel _ 

!  A  Decide 

I - 

!  ps^state  =  PSParallelState 

\  slot'  =  slot 

j 

I  AllMutuallyParallel{PM ,  slot,  items) 
items'  ~  items 
impasse'  =  *  TIE  ' 
ps^state'  =  PSFinishedState 


The  PSParallel  transition  is  defined  to  either  be  a  Mutually  Parallel  transition 
or  a  NotMutuallyParallel  transition. 

PSParallel  =  PS  Mutually  Parallel  A  PSNotMutuallyParallel 

The  operation  to  step  preference  semantics  executes  the  start  transition,  or 
one  of  the  transitions  associated  with  the  processing  for  a  specific  preference. 

PSStep  =  PSStaH  v 

PSRequire  V  PS  Acceptable  v  PS  No  Acceptable  v  PSProhibit  V  PSReject  v 
PSBetterWorse  V  PSBest  V  P5H''orjt  V  PSIndifferent  v  PSParallel 
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7.9  Working  Memory  Phase  Transitions 

Working  Memory  Phase  is  defined  in  12  transitions  (Figure  7.3). 

1.  WMPhaselnitialize  —  prepares  the  WMPhase  state  machine  for  execu¬ 
tion. 

2.  WMPhaseReset  —  resets  the  state  of  WMPhase  when  its  execution  is 
terminated  abnormally. 

3.  WMPhaseStartPickSlot  —  starts  the  loop  over  the  changed  slots. 

4.  WMPhaseStartDecideSlot  —  selects  one  of  the  changed  slots  to  decide. 

5.  WMPhaseStepDecideSlot  —  tuns  the  preference  semantics  on  the  chosen 
slot. 

6.  WMPhaseStartlmpassei  —  starts  the  execution  of  the  impasser  on  the 
slot. 

7.  WMPhaseStepImpasser  —  steps  the  impasser  state  machine. 

8.  WMPhaselmpasserFinished  —  when  the  impasser  is  finished,  this  moves 
the  machine  on  to  the  WMPhaseChangeWMState  which  adds  and  removes 
working  memory  elements  for  the  slot. 

9.  WMPbaseRemoveWME  —  this  removes  any  working  memory  elements 
no  longer  supported  by  the  slot’s  decision. 

10.  WMPhaseAddWME  —  this  adds  in  any  working  memory  elements  that 
are  required  by  the  slot’s  decision. 

11.  WMPhaseChangeWMFinished  —  when  all  of  the  required  changes  to 
working  memory  have  been  accomplished,  this  returns  control  to  selecting 
another  changed  slot. 

12.  WMPhaseFinish  —  when  all  of  the  changed  non-context  slots  have  been 
decided,  this  stops  the  execution  of  WMPhase. 

WMPhaselnitialize  initializes  the  WMPhase  by  resetting  the  state  counter. 

_ WMPhaselnitialize _ 

I  ADecide 

I  wmphasestate  =  WMPhaseFmishedSiate 
j  wmphasestate'  =  WMPhaselnitialState 
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WMPhaseReset  resets  the  system  if  WMPhase’s  operation  is  abnormally 
terminated  from  the  external  interface. 

^ _ WMPhaseReset _ 

i  ADecide 
I - 

I  wmphasestate'  —  WMPhaselniiialState 


WMPhaseStastPickSlot  moves  WMPhase  into  the  state  that  will  select  a 
changed  slot  to  decide. 

I _ WMPhase  StartPickSlot _ 

i  A  Decide 
1 _ 

I  wmphasestate  =  WMPhaselmtialState 
I  wmphasestate'  =  WMPhasePickSlotState 

The  recognition  memory  records  aU  of  the  slots  that  had  preference  changes 
during  the  last  preference  phase  in  the  set  chajigedslots.  In  the  pick  slot  state 
WMPhase  picks  one  of  these  slots  to  have  its  preferences  decided,  initiahzes  the 
preference  semantics  and  moves  to  the  state  that  decides  the  slot. 

^  WMPhaseStartDecideSlot _ _ 

ADecxde 

wmphasestate  =  WMPhasePickSlotState 

3  s  :  changed  slots  \  (GM  x  ConteztSlot  Attribute)  • 

{changed slots'  =  changedslots  \  {s}  A 
slot'  =  s) 

I  PSlnitialize 

\  slot'  =  slot 

I 

I  wmphasestate'  =  WMPhaseDecxdeSlotState 

I 
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The  WMPhaseStepDecideSlot  transition  steps  preference  semantics  until  a 
decision  htis  been  reached. 

_ WMPhaseStepDecideSlot _ 

\Decxde 

wmphaae -.state  —  WMPhaseDecideSlotState  —  wmphasestate' 

PSStep 
slot'  =  slot 


When  a  decision  has  been  reached  preference  semantic’s  precondition  is  no 
longer  satisfied,  so  WMPhaseStartlmpasser  initiabzes  the  impasser  and  moves 
WMPhase  to  the  WMPhaseImpasserSta.te  state  to  run  the  impasser. 

_ WMPhaseStartImpasser _ 

ADecide 

wmphase -State  =■  WMPhaseDecideSlotState 
pre  PSStep 
ImpasserlmUalize 
I  slot'  =  slot 

wmphase -state'  =  WMPhaseImpasserState 


The  WMPhaseStepImpasser  transition  runs  the  impasser.  The  impasser 
looks  at  the  decision  that  preference  semantics  has  created,  and  changes  working 
memory  and  impasse  memory  to  match.  If  the  decision  requires  an  impasse,  the 
impasser  will  create  it.  If  the  decision  requires  a  change  to  the  existing  impasse, 
the  impasser  will  change  it.  If  the  decision  requires  no  impasse,  the  impasser 
will  remove  any  existing  impasse.  If  the  decision  requires  no  impasse  and  none 
exists  in  memory,  the  impasser  will  make  no  changes. 

I _ WMPhaseStepImpasser _ 

'  ADecide 

\  wmphase -State  =  WMPhaseImpasserState  =  wmphasestate' 

\  ImpasserStep 

slot'  =  slot  » 
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The  WMPhaselmpasserFinjshed  transition  recognizes  when  the  impasser  has 
finished  by  checking  its  precondition.  When  it  has  completed,  it  moves  the 
WMPhase  on  to  the  state  that  changes  the  values  in  working  memory  to  match 
the  slot’s  decision. 

_ WMPhaseImpasaerFinished _ 

I  A  Decide 

wmphaae  state  —  WMPhaseJmpaaserState 
~  pre  ImpasserStep 
slot'  =  slot 

I 

j  wmphase  state'  =  WMPhaseChangeWMState _ 
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If  there  is  no  impasse,  and  there  is  not  some  element  in  working  memory 
that  the  decision  requires  then  the  WMPhaseAddWME  transition  will  add  it.  If 
the  decision  is  for  a  set  of  all  parallel  items,  then  WMPhaseAddWME  will  add 
them  all,  one  at  a  time.  If  the  decision  is  for  one  of  a  set  of  indifferent  candi¬ 
dates  and  one  candidate  is  not  already  installed,  then  WMPhaseAddWME  will 
pick  one  of  the  items  non-deterministicaUy  and  add  it  to  memory.  Chunking’s 
TtaceWME  operation  is  referenced  to  extend  the  instance  numbering  and  the 
working  memory  trace. 

_  WMPhaseAddWME _ 

ADecide 

wmphase— state  =  WMPhaseChange  WMState  =  wmphase^state' 
slot'  =  slot 
I  items'  =  items 
I  impasse  =  '  NONE  ' 

3v-.  items  ! 

I  {number _of ^winners  —  All  A 

I  {zw  :  WM  • 

w  id  =  first{slot)  A  w. attribute  =  second{slot)  A 
w. value  =  t;  A  w .context -acceptable -preference  =  No))  V 
[number -of -Winners  =  One  A 
(5  U)  ;  WM  • 

1  w.id  =  first{slot)  A  w. attribute  =  second[slot)  a 

I  w. value  E  items  A  w.  context-acceptable -preference  =  No))  • 

1  zw  :  WME  [  w  =  make  W ME  (fir  st(  slot),  second{slot),  v,  No)  A 
WM'=WMu{w}^ 

Trace  WME) 
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If  there  is  an  element  in  working  memory  that  does  not  match  the  decision, 
the  WMPhaseRemoveWME  transition  removes  it.  If  the  decision  resulted  in 
an  impasse,  then  WMPhaseRemoveWME  removes  all  of  the  working  memory 
elements  for  the  slot.  If  the  decision  resulted  in  no  impasse,  and  there  is  a  value 
in  memory  that  is  not  in  the  items  set,  then  it  is  removed.  If  the  decision  is  for  a 
set  of  mutually  indifferent  candidates  and  more  than  one  of  them  is  in  memory, 
then  all  but  one  are  chosen  non-deterministically  to  removed. 

_ WMPhaseRemoveWME _ 

i  ^Decide 

wmphasestate  =  WMPhaseChangeWMState  =  wmphase^state' 
slot'  =  slat 
items'  =  items 

3  w  :  WM 

w.  id  =  first(slot)  A  w. attribute  =  second{slot)  a 
w .context ^acceptable— preference  =  No  A 
((impasse  ■£  '  NONE  ')  v 
1  (w. value  i  items) y 

(number -of -Winners  =  One  A 

(3  W2  ■  WM  • 

u;  *  u)2  A  uij.id  =  first(slot)  A 
W'2.  attribute  =  second  (slot)  a 
W2. context-acceptable-preference  =  No  A 
wj. value  €  items)))  • 

WM'=WM\{w} 


When  no  more  elements  need  to  be  added  to  or  removed  from  working  mem¬ 
ory,  then  the  WMPhaseChangeWMFinished  transition  moves  WMPhase  back 
to  the  decide  slot  state. 

_ WMPhaseChangeWMFinished _ 

A  Decide 

:  wmphasestate  —  WMPhaseChangeWMState 

-  (pre  WMPhaseAddWME  V  pre  WMPhaseRemoveWME) 

I 

i  wmphasestate'  =  WMPhasePickSlotState 
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When  all  of  the  changed  slots  have  been  decided,  WMPhaseFinish  finishes 
WMPhase. 

I _ WMPhaseFiniih _ 

j  ADecide 

wmphaaestate  —  WMPhasePxckSlotState 
changed ^alots  \  {GM  x  ContextSlot Attribute)  =  0 
wmphaae  state'  =  WMPhaaeFinishedStaie 


The  WMPhase  is  stepped  by  taking  any  one  of  its  transitions,  with  the 
exception  of  the  initializing  transition. 

WMPhaaeStep  =  WMPhaaeStartPickSlot  V  WMPhaaeStartDecxdeSlot  V 
WMPhaaeStepDecxdeSlot  V  WMPhaaeStartlmpaaaer  V 
WMPhaaeStepImpaaaer  v  WMPhaaelmpaaaerFxnxahed  v 
WMPhaaeAddWME  V  WMPhaaeRemoveWME  V 
WMPhaaeChangeWMFinxahed  v  WMPhaaeFxnxah 


7.10  Quiescence  Phase  Transitions 

QPhase  is  very  parallel  in  structure  to  WMPhase,  but  differs  because  it  must 
walk  the  context  stack  instead  of  simply  processing  the  changed  slots.  It  adds 
in  four  transitions  to  the  basic  structure  of  working  memory  phase,  for  a  total 
of  16  transitions  (see  Figure  7.4). 

1.  QPhaselnitialize  —  initializes  QPhase. 

2.  QPhaseReset  —  resets  QPhase’s  state  when  its  operation  is  abnormally 
terminated. 

3.  QPhaseStartPickSlot  —  starts  QPhase  iterating  through  the  slots  of  the 
context  stack  from  oldest  to  newest. 

4.  QPhaseNextSlot  —  if  the  slot  under  consideration  does  not  need  to  be 
decided,  this  transition  picks  the  next  slot  in  the  context  stack  to  try. 

5.  QPhaseNoChangedPreferencesNoChangeImpasse  —  if  the  slot  under  con¬ 
sideration  has  no  changed  preferences  and  is  the  last  slot  of  the  context 
stack,  this  transition  creates  a  no-change  impasse. 

6.  QPhaseStartDecideSlot  —  this  starts  QPheise  running  the  preference  se¬ 
mantics. 

7.  QPhaseStepDecideSIot  —  this  transition  steps  preference  semantics. 
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8.  QPhaseStajtImpassez  —  when  preference  semantics  is  finished,  this  tran¬ 
sition  moves  QPhase  on  to  the  state  that  handles  impassing. 

9.  QPhaseChangedPiefeTencesNoCha.ngeImpasse  —  if  the  slot  is  the  last  slot 
of  the  context  and  heis  changed  preferences  but  the  preference  semantics 
does  not  produce  an  impasser  or  a  winning  candidate,  then  this  transition 
creates  a  no-change  impasse. 

10.  QPhaseStepImpasser  —  steps  the  impasser  on  the  current  slot. 

11.  QPhaseImpasseiFinished  —  moves  the  QPhase  from  stepping  the  impasser 
into  the  state  that  changes  working  memory. 

12.  QPhaseAddWME  —  this  transition  adds  the  working  memory  elements 
for  slots  that  preference  semantics  specifies. 

13.  QPhaseRemoveWME  —  this  transition  removes  the  working  memory  el¬ 
ements  for  the  slot  that  preference  semantics  no  longer  specifies. 

14.  QPhaseReAddWME  —  this  transition  re-adds  a  working  memory  element 
for  a  slot  that  has  been  explicitly  reconsidered. 

15.  QPhaseSlot  Unchanged  —  if  QPhase  has  not  changed  the  slot  under  con¬ 
sideration  then  this  loops  back  to  the  pick  slot  state  to  decide  another 
slot. 

16.  QPhaseSlotChanged  —  if  QPhase  has  changed  the  slot,  then  this  ends  the 
execution  of  QPhase. 

QPhaselnitiaJize  initializes  the  QPhase  state  machine  by  setting  its  state 
counter  to  the  initial  state. 

_ QPhase  Initialize _ 

S  Decide 

\ - 

qphasestaie'  =  QPhaseFini;hedState 
I  qphase -State'  =  QPhaselnitialState 

QPbaseReset  resets  the  QPhase’s  state  when  the  machine  is  terminated  ab¬ 
normally. 

_ QPhaseReset _ 

I  ADecide 

qphase^state'  =  QPhaselnitialState 
changed-slots  =  Z 
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QPhase  iterates  over  the  slots  of  the  context  from  oldest  slot  to  newest  slot. 
QPhaseSta.rtPickSlot  starts  the  loop  by  setting  the  initial  slot  to  the  top  goal 
and  the  problem-space  attribute,  and  entering  the  QPhasePickSIotState. 

_ QPhaseStartPickSlot _ 

ADecide 

j - 

I  qphasestaie  =  QPhaselnilialStaie 
'  slot  =  {top-goal,  '  PROBLEM-SPACE  ') 
qphaaestate'  —  QPhasePickSlotState 


NextContextSlot  orders  the  slots  to  allow  QPhase  to  know  which  slot  of 
the  goal  to  consider  next.  The  relation’s  minimum  is  ‘  GOAL  '  to  simplify  the 
calculation  of  the  slot  of  no-change  impasses. 

NextContextSlot  :  ContextSlot Attribute  ContextSlot Attribute 

NextContextSlot  -  {(*  GOAL  '  P  lOBLEM-SPACE  '), 
(’PROBLEM-SPACE  ,•  STATE'), 

(’STATE', 'OPERATOR')} 

QPhase  must  know  when  the  slot  it  is  deciding  is  the  last  one  that  it  should 
consider  for  this  impasse.  If  the  slot  is  the  operator,  it  is  the  last  to  check  as 
it  is  the  last  in  the  impasse,  if  the  context  does  not  have  a  working  memory 
element  in  memory  for  the  slot,  then  it  is  the  last  one  to  check,  e.g.,  you  can’t 
install  an  operator  unless  there  is  a  state. 

LaatSlotToCheckInContext- :  P(Slot  x  P  V’'ME) 

i  Vs  Slot:  WM  :  P  WME  • 

LastSlotToCheckInContext{s ,  o 
(secon(l(s)  =  'OPERATOR'  v 
(3  10  :  WM  • 

w.id  =  first{s)  A  w. attribute  =  second(s)  a 
w.  context -acceptable -preference  =  No)) 
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QPhclse  uses  the  LastSlotToChecklnContextStack  predicate  to  determine  the 
last  one  of  the  context  stack  for  it  to  process.  A  slot  is  the  last  one  to  check 
in  the  stack  if  it  is  the  last  slot  to  check  in  the  last  impasse.  It  will  signal  a 
no-change  impasse  for  the  last  filled  slot  if  preference  semantics  can  no*,  reach 
a  conclusion  about  this  slot. 

LastSlotToChecklnContextStack^  :  P{Slot  x  P  Identifier  x  P  WME) 

V  s  :  Slot',  CM  :  P  Identifier-,  WM  :  P  WME  • 
LastSlotToCheckInContextStack{s.  CM .  WM)  o 

-<{3g  :  CM  •  makeWME(g,'  OBJECT'  ,first{s),  No)  G  WM)  A 
I  LastSlotToCheckInContext{s,  WM) 

QPhase  must  decide  a  context  slot  if  there  is  no  value  for  it  in  working 
memory  and  there  are  preference  changes,  or  if  there  is  a  value  in  working 
memory  and  there  is  a  reconsider. 

DecidableSlot_  :  P(5/o<  x  P  WME  x  P  Preference  x  P  Slot) 

V  slot  :  Slot',  WM  :  P  WME',  PM  :  P  Preference,  changed^slots  :  P  Slot  • 
Decidable Slot( slot.  WM ,  PM  changed ^slots)  o 

(3  ti  :  Symbol  • 

makeWME(first(slot),  second{slot) .  V ,  No)  G  WM)  A 
slot  G  changed ^slots)  v 
(3  t)  :  Symbol  • 

makeWME [first) slot ).  second{slot),v ,  No)  G  WM  A 

make  Unary  Preference(first{slot),  second[slot),  v,'^')  G  PM) 
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While  QPhase  is  iterating  across  the  context  stack,  QPhaseNextSIot  allows 
QPhase  to  skip  slots  that  do  not  need  to  be  decided.  If  the  slot  that  QPhase  is 
working  with  is  not  decidable  and  it  is  not  the  last  slot  to  check,  then  it  picks 
the  next  slot  to  decide.  If  the  slot  is  not  the  last  in  this  context  to  check,  it 
moves  to  the  next  slot  in  the  same  context.  If  the  slot  is  the  last  in  this  context 
to  decide,  it  starts  on  the  problem  space  of  the  next  context. 

_ QPhaseNextSIot _ 

I  NDecide 

qphase^state  =  QPhasePickSlotState  =  qphase^state' 

DecidahleSlot{slot,  WM ,  PM ,  changed^slots) 

LastSlotToCheckInContextStack{slot,  GM ,  WM) 

LastSlotToCheckInContext(slot,  WM)  => 

slot'  =  {first{slot),  NextContextSlot{second{slot))) 

LastSlotToCheckInContext{slot,  WM)  => 

(E  sg  :  GM  make  WME{sg, '  OBJECT ' ,  first(slot),  No)  £  WM  m 
slot'  =  (sg, '  PROBLEM-SPACE  ')) 


If  QPhase’s  loop  down  the  context  stack  takes  it  to  the  last  slot  in  the 
context,  and  this  slot  has  no  preference  changes,  this  transition  signals  a  no¬ 
change  impasse.  The  no  change  impasse  is  for  the  last  filled  slot  of  the  context, 
or  if  the  context  has  no  filled  slot  it  is  a  goal  no-change. 

, _ QPhaseNoChangedPreferencesNoChangeImpasie _ 

ADecide 

qphase^state  =  QPhasePickSlotState 

I 

-  DecidableSlot{slot,  WM .  PM ,  changed^slots) 

I  LaatSloiToCheckInConteztStack{slot.  CM ,  WM) 

(3  tiJ  :  WM  •  w.xd  =  first{slot)  A  w. attribute  —  second[slot)  A 
j  w  .context  ^acceptable  ^preference  =  No)  => 

slot'  =  {first{slot),  NextContextSlot'~{second(slot))) 

(3  w  :  WM  •  w.td  =  first(slot)  A  w. attribute  =  second[slot)  A 
'  w  context -acceptable ^preference  =  No)  => 

slot'  =  {first(slot) ,  second{slot)) 

ImpasserIntUahze 

impasse'  =  'NO-CHANGE' 

items'  =  0 

I  qphasestate'  =  QPhaseImpasserState 

If  there  are  changed  preferences  for  a  slot,  QPhase  moves  to  the  QPhaseDe- 
cideSIotState  to  step  preference  semantics.  The  slot  to  be  be  decided  is  removed 
from  the  changed_slots  set  so  that  it  is  not  decided  again. 

_ QPhaseStartDecideSlot _ 

ADecide 

qphasestate  =  QPhasePickSlotState 
DecidableSlot{slot,  WM .  PM .  changed  slots) 
changed  slots'  =  changed  slots  \  {slot} 

PSlnitialize 

'-ntext -changed  =  Unchanged 
qphasestate'  —  Q  Phase  DecideSlotState 
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QPhaseStepDecideSlot  steps  preference  semantics  on  the  current  slot. 


_ QPhaseStepDecideSlot _ 

A  Decide 

qphase -State  =  QPhaseDecideSlotState  =  qphase  state' 
PSStep 


When  preference  semantics  has  finished,  this  transition  moves  QPheise  to  the 
QPhaselmpasserState  to  step  the  impasser.  The  impasser  will  add  an  impasse, 
remove  an  old  impasse,  change  the  items  of  the  existing  impasse,  or  do  nothing 
depending  upon  the  contents  of  working  memory  and  the  results  of  preference 
semantics. 

_ QPhaseStartlmpasser _ 

A  Decide 

qphase  state  =  QPhaseDecideSlotState 
pre  PSStep 

LastSlotToCheckInContextS  tack  [slot,  GM ,  WM)  V 
impasse  '  NONE  '  V 
items  ^  0 

Impasser  Initialize 

i  qphase  state'  —  Q  Phase  Impasser  State 
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If  the  slot  under  consideration  is  the  last  slot  in  the  context  and  preference 
semantics  has  no  winner,  then  QPhaseChangedPreferencesNoChangelmp&sse 
sets  the  impasse  to  no-change  before  starting  the  impasser. 

_ QPhaseChangedPreferencesNoChangelmpasae _ 

A  Decide 

qphaae  state  =  QPhaseDecideSlotState 
pre  PSStep 
items  —  0 
impasse  =  '  NONE  ' 

LastSlotToCheckInContextStack{slot,  GM ,  WM) 

~  {3  w  :  WM  m  w.td  =  first{slot)  A  w.  attribute  —  second  (slot)  a 
w.  context  acceptable  ^preference  =  No) 
slot'  =  (first(slot),  NextContextSlot''  (second[slot))) 

(~  w  :  WM  •  w.id  =  first{slot)  z'  w. attribute  =  secondi slot)  \ 
w .  context -acceptable  ^preference  —  No)  => 
slot'  —  {first(slot).  second{slot)) 

Impasserlnitialize 

qphasestate'  =  QPhaseImpasser  State 
QPhaseStepImpasser  steps  the  impasser  state  machine. 

_ QPhaseStepImpasser _ 

A  Decide 

qphasestate  =  QPhaseImpasser  State  =  qphasestate' 

ImpasserStep 

When  the  impasser  is  finished,  QPhaselmpasserFinished  moves  QPhase  on 
to  Change WMState  to  add  and  remove  working  memory  elements  for  the  slot. 

_ QPhaselmpasserFinished _ 

ADecide 

qphasestate  =  QPhaseImpasserState 
pre  ImpasserStep 

qphasestate'  ■=  QPhaseChange  WMState 
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Whenever  QPhase  changes  a  context  slot,  it  must  clear  out  aU  of  the  work¬ 
ing  memory  elements  for  the  lower  slots  of  the  same  context.  LaterSlotsOfCon- 
textSlot  returns  the  working  memory  elements  for  the  later  slots  so  that  they 
can  be  removed  from  working  memory. 

LaterSlotaOfContextSlot  :  Slot  x  P  WME  — *  P  WME 

V  s  :  Slot  ;  WM  :  P  WME  • 

LaterSlotsOfContextSlot(s,  WM)  = 

I  {u;  :  WM  i  w.id  =  first{s)  A  w. context -acceptable ^preference  —  No  A 

{{second{s)  =  *  PROBLEM-SPACE  '  A 

j  w. attribute  e  {'  STATE  '  OPERATOR  '})  V 

(second(s}  =  'STATE'  A  w. attribute  =  'OPERATOR'))} 

If  the  preference  semantics  produces  a  set  of  items  and  no  impeisse,  and  none 
of  the  items  is  in  working  memory  then  QPhaseAddWME  adds  a  working  mem¬ 
ory  element  for  one  of  the  items.  The  item  used  is  picked  non-deterministically. 

It  marks  the  context  as  changed  so  that  QPhase  knows  that  it  has  found  a 
change  and  that  it  should  stop  iterating  across  the  slots.  As  it  does  this,  it  also 
deletes  all  of  the  later  slots  for  the  same  context. 

„  QPhaseAddWME _ 

ADecide 

qphasestate  =  QPhase  Change  WMState  =  qphase state' 

impasse  =  'NONE' 

(3  u'  :  WM  •  w.id  =  first{slot)  A  w. attribute  =  second{slot)  A 
w .  context-acceptable -preference  =  No  a  w. value  G  items) 

context -changed  =  Unchanged  =>  context -changed'  =  Changed 

3  j  :  items:  w  :  WME  \  w  =  makeWME{first{slot),  second{slot),  i,No)  • 
{CM'  =  CM  \  GoalDescendants{first{slot),  CM,  WM)  A 
WM'  =  WM  \  LaterSlotsOfContextSlot[slot.  WM) 

I  ^ 

j  TraceWME) 
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QPhaseRemoveWME  deletes  any  elements  for  the  context  slot  that  are  not  in 
the  items  set  decided  by  preference  semantics.  It  marks  the  context  changed  and 
deletes  the  elements  for  later  slots.  The  one  exception  to  this  rule  is  that  context 
slots  are  not  emptied  for  no-change  impasses.  It  also  updates  the  bottom_goaJ 
pointer,  in  case  it  has  deleted  context  impasses. 

. _ QPhaseRemove  WME _ 

^Decide 

qphasesiate  =  QPhaaeChangeWMState  =  qphaae^ataie' 

1  context  ^changed  =  Unchanged  =>  context  ^changed'  =  Changed 
!  5  lu  :  WM  I 

w.  id  =  first{slot)  A  w. attribute  =  aecond[slot)  A 
w .context -acceptable ^preference  =  No  A 
w. value  $  itema  • 

i  WM'  =  WM  \  {r  ;  WM  !  r  =  «;  A  impaaae  '  NO-CHANGE  '} 

\  Later SlotaOfContextSlot{alot,  WM) 

bottom -goal'  =  fir at(alot) 
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Sometimes,  QPhase  re-decides  an  installed  slot  because  it  has  a  reconsider 
preference  and  preference  semantics  produces  no  impasse  and  an  items  set  that 
holds  the  instaJled  value.  QPhaseReAddWME  re-installs  this  candidate  by  re¬ 
moving  the  working  memory  element,  the  lower  context  slots,  all  subgoals  and 
their  architecturally  created  elements,  and  then  re-adds  the  working  memory 
element. 

_  QPhaseReAddWME _ 

j  ^.Decide _ 

j  qphase^state  =  QPhaseChangeWMState 

I  context-changed'  =  Changed 

1 

1  tmpasje  = 'NONE' 

=  w  :  WM  ! 

w.id  =  first{slot)  A  w. attribute  =  second(slot)  A 
w.  context-acceptable -preference  —  No  A 
w.  value  €  items  A 

make  Unary  Preference{first{slot),  second(slot) ,  w. value,  '® ')  €  PM 
[GM'  =  GM  \  GoalDescendants(first(slot),  GM ,  WM)  A' 

WM'  =  ITM  \  {u)} 

\  Later  Slots  OfContextSlot{slot ,  WM ) 

\(U{5  ■  GoalDescendants{first(slot),  GM,  WM)  • 
lmpassesWMEs{g,  GM,  WM)}) 

j{w}  A 

Trace  WME) 
qphase  state'  =  QPhaseFinishedState 

If  working  memory  is  already  consistent  with  the  decision  for  the  slot  then 
QPhaseSIotVnchanged  will  recognize  that  the  context  is  unchanged  and  move 
QPhase  back  into  the  pick  slot  state  to  continue  the  loop  over  the  slots. 

_ QPhaseSlotUnchanged _ 

ADectde 

qphasestate  =  QPhaseChangeWMState 
—  (pre  QPhaseAddWME  v  pre  QPhaseRemoveWME) 
context -changed  =  Unchanged 
\  qphasestate'  =  QPhasePickSlotState 


If  neither  the  Impasser  or  the  ChangeWMS tate  have  changed  memory  and 
all  adds  and  removes  have  occurred,  then  QPhaseSIotChanged  finishes  the  exe¬ 
cution  of  QPhase. 

_ _ QPhaseSIotChanged _ 

I  A  Decide 

j  qphase^state  —  QPhaseChangeWMState 

^  (pre  QPhase AddWME  v  pre  QPhaseRemoveWME] 

!  context -changed  —  Changed 
I  qphase  state'  =  QPhaseFinishedState 


QPhaseStep  drives  the  QPhase  one  step  forward  in  the  state  machine  by 
executing  one  of  the  QPhase  state  transitions. 

QPhaseStep  =  QPhaseStartPickSlot  v  QPhaseNextSlot  V 
Q PhaseN oChangedPreferencesNoChangelmpasse  V 
Q PhaseStartDecideSlot  v  QPhaseStepDecideSlot  v 
Q Phases tartlmpasser  v  QPhaseStepImpasser  v 
QPhaseChangedPreferencesNoChangelmpasse  V 
QPhaseImpasserFinxshed  v 

QPhaseRemoveWME  v  QPhaseAddWME  v  QPhaseReAddWME  v 
QPhaseSlotUnchanged  V  QPhaseSIotChanged 
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Chapter  8 

Top  Level 


The  actions  of  Soar’s  modules  are  sequenced  by  a  top  level  state  machine  that 
steps  the  various  control  points  of  each  module.  Recognition  memory  is  stepped 
through  preference  phase.  Decide  is  stepped  through  WMPhase  and  QPhase. 
lO  is  stepped  through  the  input  cycle  and  the  output  cycle. 

This  chapter  specifies. the  states  of  the  top  level  state  machine,  Soar’s  state 
schema  and  the  transitions  of  the  top  level  state  machine. 


8.1  The  States  of  the  Top  Level 

Soar’s  top  level  state  machine  has  ten  states  (Figure  8.1). 

1.  TLLnitialState  —  the  machine  starts  here  when  initialized. 

2.  TLDecisionCycIeState  —  the  top  level  enters  this  state  before  starting 
each  decision  cycle. 

3.  TLEIaborationPhaseState  —  the  top  level  enters  this  state  before  starting 
each  elaboration  phase. 

4.  TLElaborationCydeState  —  the  top  level  enters  this  state  before  starting 
each  elaboration  cycle. 

5.  TLInputCydeState  —  the  top  level  uses  this  state  to  step  the  input  cycle 
state  machine. 

6.  TLPreferencePhaseState  —  the  top  level  uses  this  state  to  step  the  pref¬ 
erence  phase  state  machine. 

7.  TLWorkingMemoryPhaseState  —  the  top  level  uses  this  state  to  step  the 
working  memory  phase  state  machine. 
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8.  TLOutputCycleSt&te  —  the  top  level  uses  this  state  to  step  the  output 
cvcle  state  machine. 


9  TLDecisionPhnseState  —  the  top  level  uses  this  state  to  step  the  quies¬ 
cence  phase  state  machine. 

10.  TLFinishedState  —  the  state  that  the  top  level  enters  when  the  system 
is  halted.  There  is  no  way  to  reach  this  state  in  the  specification  because 
Soar  is  a  situated  agent  that  behaves  continuously,  i.e.,  Soar  never  turns 
itself  off.  However,  an  implementation  would  have  commands  that  ter¬ 
minate  Soar’s  execution  by  moving  the  top  level  state  machine  into  its 
TFFinishedState. 


TopLevelSiaie 


TLImtialState 

TLDeciaionCycleState 

TLElaborationPhaseSiate 

TLElaborationCycleState 

TLInputCycleSiate 

TLPreferencePhaseState 

TLWorktngMemoryPhaseStaie 

TL  OutputCycleSlate 

TLDecistonPhaseState 

TLFimshedState 


The  state  schema  for  the  top  level,  TL  just  holds  a  state  counter  of  type 
TopLevelState. 


^TL _ 

j  top-level  state  :  TopLevelState 


8.2  Soar’s  State  Schema 

The  Soar  state  schema  contains  the  state  schemas  for  recognition  memory,  10, 
and  Decide.  It  also  includes  the  state  schema  for  the  top  level  (TL).  The  Iden¬ 
tifier  Table  is  defined  to  be  the  union  of  aO  of  the  component  identifiers  of  the 
productions,  temporary  memory  elements,  components  and  traces. 
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Figure  8.1:  Top  Level  State  Machine 
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_ Soar - 

I  RM 

I  10 

Decide 

TL 

Identifier  Table  :  P  Identifier 

Identifier  Table  = 

{\J{SpsComponenta  (j5PAf|)u 
TM Es  Components  ^TM^'U 
TracesComponentsl^ia.R  7V/’[|)n 
Identifier) 


The  InitSo&t  schema  specifies  the  valid  initial  configurations  for  Soar.  It 
constrains  Soar’s  initial  configuration  to  be  an  initial  configuration  for  recogni¬ 
tion  memory,  10  and  decide,  and  the  top  level  state  machine  must  start  in  the 
TLInitialState  state. 

_ InitSoar _ 

Soar 

InitRM 

ImtIO 

^  InitDecide 

top -level -State  =  TLInitialState 


8.3  The  Top  Level  State  Machine 

TLInitialize  initializes  the  top  level  state  machine.  Soar  never  initializes  itself; 
only  the  user  interface  will  ever  invoke  this  operation 

_ TLInitialize _ 

A  Soar 

I 

I 

I  top -level-state  =  TLFinishedState 
top -level -State'  =  TLInitialState 


TLReset  resets  the  top  level  state  machine  to  its  initial  configuration  from 
any  of  its  states.  The  top  level  state  machine  might  have  been  stepping  one  or 
more  of  the  hierarchy  of  sub-state  machines,  so  it  resets  their  states  also. 
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r 


TLResei _ 

\SoaT 

top -lev  el  state'  =  TL  Initials  tate 

PPhaseReset 

InpuiCycleReset 

OutputCycleReaei 

QPhaaeResei 

WMPhaseReset 


TLStajtSoar  moves  Soar  from  its  initi2il  state  into  the  TLDecisionCycleState. 
The  TLDecisionCycleState  is  where  each  iteration  of  a  decision  cycle  is  started. 
When  Soar  is  .^irst  started,  this  transition  initializes  decide’s  first  goal  with 
DecideCteateF  irs  t  Goal. 

_ TLStartSoar _ 

I  A  Soar 

top -lev  el  state  —  TL  Initials  tate 
DecideCreateFirstGoal 
I  top -lev  el  state'  =  TLDecisionCycleState 


TLStartDecisionCycle  moves  from  the  TLDecisionCycleState  into  the  TLE- 
laborationPhaseState  starting  the  first  elaboration  phase  of  the  decision  cycle. 

_ TLStartDecisionCycle _ 

A5oor 

top -level  state  —  TLDecisionCycleState 
\  top -level  state'  =  TLElaborationPhaseState 


The  elaboration  phase  consists  of  many  elaboration  cycles;  so  the  TLStartE- 
laborationPhase  transition  moves  the  lop  level  from  the  TLElaborationPhaseS¬ 
tate  into  the  TLEIaborationCycleState. 

_ TLStartElaborationPhase _ 

ASoor 

j  top -level  state  =  TLElaborationPhaseState 
'  top -level  state'  =  TLEIaborationCycleState 
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Each  elaboration  cycle  is  an  input  cycle,  then  a  preference  phase,  a  working 
memory  phase  and  finally  an  output  cycle.  TLStaitElaborationCycle  moves 
from  the  TLElaborationCycieState  into  the  TLInputCycleState  to  start  the 
elaboration  cycle  by  starting  the  input  cycle.  It  initializes  the  input  cycle  state 
machine  for  execution,  so  SoarInputCycleState  can  step  the  input  cycle  state 
machine. 

, _ TLStartElaborationCycle _ 

j  ASoar 

top-level^siate  =  TLElaborationCycieState 
InputCyclelnitialize 

' 

I  top-level  state'  =  TLInputCycleState 


TLStepInputCycle  moves  the  input  cycle  state  machine  one  step. 

_ TLStepInputCycle _ 

I  ASoar 

j  top^levelstate  =  TLInputCycleState  =  top^levelstate' 

!  InputCycleStep 


When  the  input  cycle  state  machine  has  finished,  if  Soar  is  not  at  Quies¬ 
cence,  TLStartPreferencePhase  moves  to  TlPrefetencePhaseState  to  start  the 
preference  phase. 

I _ TLStartPreferencePhase _ 

j  ASoar 

r — —  ■  "  

I  top-level  state  =  TLInputCycleState 
pre  InputCycleStep 
->  Quiescence 

top^levelstate'  =  TLPreferencePhaseState 


If  Soar  is  at  Quiescence  then  TLStartDecisionPbase  moves  Soar  to  the  TLDe- 
cisionPhaseState  to  start  the  decision,  and  initializes  QPhase. 
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_ TLStariDecistonPhase _ 

1  A  Soar 

1  top-level— state  =  TLInputCycle  State 
I  -  pre  InputCycleStep 
j  Quiescence 

QPhaselnitialize 

top-level^state'  =  TL  DecisionPkaseState 

TLStepPreferencePhase  steps  the  preference  phase. 

TLStepPreferencePhase _ 

!  A  Soar 

top_level-state  —  TLPreferencePhaseState  =  top_level^state' 

I  PPhaseStep 

When  the  preference  phase  has  finished  its  work,  TLStartWoTkingMemo- 
’vPhase  moves  Soar  from  TlPreferencePhaseState  into  TLWoTkingMemoTvPhas' 
eState. 

_ TLStartWorking  Memory  Phase _ _ _ _ — 

A  Soar 

I 

top-level -State  =  TLPreferencePhaseState 

—  pre  PPhaseStep 

WMPhaselnitialize 

top -level -State'  —  TLWorkingMemoryPhaseState 

TLStepWorkingMemory Phase  steps  the  working  memory  phase. 

, _ TLStepWorkingMemoryPhase _ 

A  Soar 

top -level -State  =  TLWorkingMemoryPhaseState  =  top -level-state' 
WMPhaseStep 

When  the  working  memory  phase  has  finished,  TLStartOutputCycIe  initial¬ 
izes  the  output  cycle  and  moves  Soar  to  TLOutputCycleState. 
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_ TLStartOMtpvtCycle _ 

^Soar 

top^level^state  =  TLWorking  Memory  Phase  State 
pre  WMPhaseStep 

top^level^state'  =  TLOutputCycleState 
OutputCyclelnitialize 


TLStepOutputCycle  steps  the  output  cycle. 

_ TLStepOutputCycle _ 

ASoar 

top^level^state  =  TLOutputCycleState  =  top -level-state' 
OutputCycleStep 


When  the  output  cycle  has  finished  its  work,  TLEndElabora-tionCycIe  moves 
Soar  back  to  the  EJaborationPhaseSCate  to  start  the  next  elaboration  cycle  of 
the  elaboration  phase. 

_ TLEndElaborationCycle _ 

ASoar 

top -level-state  =  TLOutputCycleState 

^  pre  OutputCycleStep 

top -level -State'  =  TLElaborationCycleState 


TlStepQPhase  steps  QPhase  in  the  DecisionPhaseState. 

I _ TLStepQPhase _ 

ASoar 

top-level-state  =  TLDecisianPhaseState  =  top -level  state' 
QPhaseStep 


When  the  quiescence  phase  has  finished,  TLEndDecisionCycIe  moves  Soar 
back  to  the  Decision  CycJeState  to  start  the  next  decision  cycle  of  the  decision 
phase. 
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TLEndDecisionCycle _ 

!  A5oar 

top-level^staie  =  TLDecisionPhaaeState 
-1  pre  QPhaseSiep 

top-level-state'  =  TLDecisionCycleState 


TLStep  steps  the  entire  execution  of  Soar  by  moving  the  top  level  state 
machine  through  one  of  its  transitions. 

TLStep  =  TLStartSoar  V  TLStartDecisionCycle  V 

TLStartElaborationPhase  v  TLStartElaborationCycle  V 
TLStepInputCycle  V  TLStartPreferencePhase  V 
TLStartDecisionPhaae  V  TLStepPreferencePhaae  v 
TLStariWorkxngMemoryPhaae  v  TLStep WorkingMemoryPhaae  V 
TLStartOutputCycle  v  TLStepOutputCycle  V 
TLEndElaborationCycle  V 
TLStepQPhaae  V  TLEndDeciaionCycle 
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Appendix  A 

Numbers 


We  have  specified  a  Soar  that  uses  only  constants  and  identifiers  to  construct 
its  temporary  memory  structures.  Tdeaily,  the  implementation  would  also  use 
exactly  the  same  data  structures.  Unfortunately,  Soar  users  firi  it  difficult  to 
effectively  process  numbers  without  some  implementation  support.  The  long 
term  solution  is  to  provide  problem  spaces,  complete  with  chunk  libraries,  that 
gracefully  support  numeric  reasoning,  and  some  work  in  this  direction  has  al¬ 
ready  been  completed.  In  the  interim,  we  augment  our  implementation's  base 
data  structures  with  numeric  constants  and  extend  the  test  structure  to  let 
productions  match  against  them  with  the  basic  arithmetic  relations. 

The  implementation  adds  in: 

Number  :  P  Constant 
>,<,>  =  ,<=  :  Sp'XialSymbol 
NumericRelationSymbols  :  P  SpecialSyrr.bol 

j  NumericRelationSymbols  =  {>,<,>  =  ,<=} 


Test  ::=  RelationalTest{{NumericRelationSymbols  x  (  Variable  U  Number))) 


V  t  :  i&n  RelationalTest  •  TestsComponents[t)  —  second{RelationalTest'“ yt )) 


V  t  :  ran  RelationalTest  •  TestsPositiveComponents(t)  =  0 


We  extended  Matches with  some  extra  cases  to  handle  numeric  re¬ 
lations  and  same  type  tests  must  be  extended  to  differentiate  numbers  from 


identifiers  and  other  constants. 
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Ma.tchesg^^^j  _  :  P {Binding  x  Teat  x  Symbol) 

V  b  :  Binding-,  I  :  Teat,  v  :  Symbol  • 

MatchesJ^-^bol  ^ 

((t  €  tan  RelationalTeat  A 

(3  nravn  :  {RelaiionalTeaf^ (t)}  • 

(3  vn  :  {((id  S)  0  b){aecond{nravn))}  • 

(3  t  :  {firat{nravn)}  • 

{t  =  >  :^  V  >  «n)  A 
{t  =  <  ^  V  <  un)  A 
(t  =  >=  =s>  t)  >=  vn)  A 
(i  =<==>«<=  vn)))))  V 
(t  €  ran  SameTypeTeat  A 

(3v2  ;  {((id  Symbol)®  b){SameTypeTeat^ (t))}  • 


((v  €  Identifier  A  v2  €  Identifier)  V 
(«  €  Conatant  \  Number  A  v2  G  Conatant  \  Number)  v 
(v  G  Number  A  v2  G  Number))))) 
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Appendix  B 

An  Implementation 
Discipline 


Section  B.l  details  a  technique  to  allow  users  to  observe  and  modify  the  im¬ 
plementation  of  Soar.  Section  B  defines  an  implementation  discipline  to  govern 
implementations  of  the  specification.  The  final  section.  Section  B.3,  calculates 
the  worst  case  cost  of  actually  using  the  state  machine  representation  for  Soar’s 
control. 


B.l  Observing  Soar’s  Operation 

As  Soar  is  a  research  vehicle  for  cognitive  modeling  and  artificial  intelligence 
work  ([New90]),  we  would  like  to  have  an  implementation  that  we  can  easily 
monitor  and  modify.  We  require  a  specification  and  implementation  discipline 
that  helps  us  to  support  these  goals.  In  previous  implementations,  if  a  researcher 
wanted  to  measure  the  frequency  of  a  certain  type  of  chunk  creation,  she  would 
have  to  read  large  tracts  of  the  source  code  and  install  her  statistics  directly  in 
a  copy  of  the  code.  As  there  was  no  other  detailed  enough  description  of  the 
system,  only  the  code  was  an  effective  index  into  the  system’s  operation. 

Coupling  this  specification  with  an  implementation  discipline  would  allow’ 
Soar  researchers  to  more  easily  solve  this  problem.  In  (PMN911  we  describe  a 
technique  called  Hooking  that  allows  the  system  to  execute  a  function,  called 
an  Observer,  before  and  after  the  execution  of  any  sequential  operation.  The 
technique  also  allows  the  user  to,  at  run-time,  redefine  any  specified  operation; 
as  long  as  the  new  implementation  meets  this  specification  of  the  operation  in 
this  document.  Researchers  could  then  use  this  specification  as  a  guide  to  place 
observers  on  hooks  that  monitor  or  change  the  implementation’s  operation. 
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B.2  An  Implementation  Discipline 

This  section  defines  an  implementation  discipline  that  maps  parts  of  this  spec¬ 
ification  into  executable  code  This  discipline  was  designed  to  allow  the  easy 
observation  and  modification  of  Soar,  but  the  new  implementation  of  Soar, 
Soar6,  is  not  constructed  using  this  technique. 

Ideally,  we  would  like  to  semi-mechanicaUy  map  specifications  into  an  opti¬ 
mized  implementation.  However,  the  automation  of  this  mapping  is  a  difficult 
research  problem  in  program  synthesis,  so  we  have  settled  for  an  informal  man¬ 
ual  mapping. 

The  Soar  specification  contains  four  types  of  objects  that  must  be  mapped 
into  the  implementation: 

1.  state  schemas  —  defined  using  schemas 

2.  sequential  operations  —  defined  using  schemas  with  A  in  their  signature 

3.  data  structures  —  defined  using  base  types,  free  types  and  schemas 

4.  state  machines  —  built  of  state  schemas  and  sequential  operations 

This  discipline  maps  each  state  schema  into  a  structure  of  the  same  name 
in  the  implementation.  These  structures  contain  fields  for  the  schema  s  compo¬ 
nents  and  may  contain  other  fields  for  implementation-specific  information. 

Mapping  Sequential  Operations  Each  sequential  operation  is  mapped  to 
a  function  of  the  same  name  in  the  implementation.  Some  of  the  sequential 
operations  take  inputs  using  the  Z  “?”  decoration  convention  ([Spi89'  133)  and 
many  non-deterministically  select  their  arguments  from  sets  using  existential 
quantification.  The  observers  are  passed  all  arguments  and  top  level  existentially 
quantified  variables  to  simplify  their  observation  of  the  operation. 

Associated  with  each  state  changing  function  are  two  sets  of  observer  func¬ 
tions,  called  hook  sets,  and  an  optional  implementation  function.  The  observer 
functions  in  the  first,  or  pre-hook  set,  are  called  before  the  operation  function 
executes.  The  observer  functions  in  the  second,  or  post  hook  set,  are  called 
after  the  operation  function  executes.  The  observer  functions  may  inspect  any 
part  of  Soar’s  state,  but  may  not  change  Soar's  state.  The  observers  allow  users 
to  instrument  Soar’s  state  changes.  If  an  implementation  function  has  been 
specified  it  is  called  instead  of  the  default  sequential  operation  function.  This 
would  allow  researchers  to  easily  change  small  pieces  of  the  implementation. 

Soar’s  specification  currently  has  about  150  state  changing  operations  and 
most  users  will  never  care  to  observe  or  modify  any  of  them.  At  the  time  the 
Soar  implementation  is  compiled,  the  user  would  be  able  to  turn  on  only  the 
hooks  she  requires.  Any  hooks  not  switched  on  would  produce  no  code  in  the 
resulting  implementation  and  so  have  no  run-time  cost.  If  an  operation  has  been 
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compiled  to  allow  hooking,  the  hook  set  and  implementation  could  be  filled  at 
run-time,  allowing  choice  as  to  when  as  well  as  where  to  hook. 

Mapping  Data  Structures  The  mapping  to  generate  the  data  structures 
is  much  less  mechanical.  Implementations  of  data  structures  must  be  carefully 
selected  for  efficiency.  Basic  types  would  generally  be  represented  using  enu¬ 
merations,  structures  or  built-in  types  such  as  numbers.  Schemas  that  define 
data  types  would  mostly  be  represented  using  structures.  Free  types  that  define 
only  constants  would  be  represented  as  enumerated  types.  Free  types  that  use 
injections  to  define  types  would  generally  be  represented  by  structures  using 
tags  and  union  types.  Mappings  and  sets  would  be  represented  in  a  -variety  of 
ways  including  pointers,  lists,  functions  and  hash  tables. 

Mapping  State  Machines  The  specification’s  state  machines  are  constructed 
of  state  schemas  and  sequential  operations.  As  above,  each  state  schema  would 
be  represented  by  a  structure  and  each  transition  by  a  function.  However,  many 
states  of  the  machines  have  more  than  one  transition  leaving  the  state.  The  state 
machine’s  implementation  must  choose  which  of  these  transitions  to  apply.  Ev¬ 
ery  state  that  has  more  than  one  transition  is  mapped  to  a  function  of  the  same 
name  that  chooses  which  transition  to  apply. 

Some  transitions  in  the  state  machines  check  the  pre-condition  of  the  step 
operation  of  a  sub-state  machine.  For  example,  FinishOP  checks  ^  pre  StepSZ. 
The  implementation  could  check  these  pre-conditions  by  checking  the  state 
counter  of  the  sub-state  machine.  If  the  machine  is  in  any  state  other  than 
the  final  state,  its  pre-condition  is  satisfied. 

Some  transitions  check  the  pre-condition  of  other  operations:  StartSJ  checks 
-  pre  S2.  The  implementation  is  free  to  calculate  this  pre-condition  in  any  way 
that  does  not  allow  a  user  of  the  system  to  observe  performance  different  than 
that  described  by  the  specification.  A  fast  way  to  check  this  is  to  have  the  state 
function  (in  this  case,  S2State’s  function)  record  that  the  pre-conditions  of  S2 
no  longer  holds  on  S2’s  last  execution.  For  example,  if  S2  is  iterating  over  a 
set  of  inputs,  when  the  set  is  empty  it  wiU  mark  that  its  pre-condition  is  no 
longer  satisfied  in  a  flag.  When  the  S2State  function  is  called  to  select  the  next 
transition,  it  will  consult  the  pre-condition  flag  and  select  StartSJ. 

B.3  An  Estimate  of  the  Cost  of  Using  State 
Machines 

The  use  of  state  machines  for  control  in  an  implementation  would  have  a  greater 
efficiency  cost  than  using  standard  sequential  code  for  control.  This  section  uses 
an  analytic  and  empirical  analysis  to  demonstrate  that  the  expense  of  state 
machine  control  is  at  worst  a  small  percentage  of  Soar’s  total  cost.  First,  we 
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describe  an  implementation  of  the  state  machines  in  detail.  Second,  we  identify 
the  most  expensive  step  of  state  machine  control.  Third,  we  prototype  just  this 
step  and  benchmark  it.  Fourth,  we  estimate  the  number  of  such  steps  in  a  large 
Soar  run  and  compare  our  measured  cost  with  execution  times  from  Soar5  and 
optimistic  speed-up  factors  for  Soar6. 

The  implementation  of  each  state  machines  has  five  parts: 

1.  a  stepping  function 

2.  a  state  name  counter 

3.  an  array  that  the  stepping  function  uses  to  index  into  the  state  functions 

4.  a  function  for  each  state  that  selects  which  transition  to  apply 

5.  a  function  for  each  transition 

For  each  transition  of  a  state  machine,  first  the  stepping  function  is  called. 
It  indexes  using  the  state  name  into  the  array  of  state  functions  and  calls  the 
function  for  the  current  state.  This  function  calculates  which  of  the  possible 
transitions  to  execute,  and  applies  one.  Thus  for  each  step  of  a  state  machine. 
Soar  performs  three  function  calls  and  one  array  access.  A  sequential  control 
model  would  represent  the  stepping,  the  array  access  and  the  state  function  in 
sequential  code. 

At  the  deepest:  the  specification  nests  state  machine  control  only  three  levels. 
The  most  expensive  step  is  likely  to  be  the  state  machine  to  calculate  preference 
semantics,  as  it  must  execute  once  for  every  change  to  any  temporary  memory 
slot.  The  longest  execution  path  through  this  state  machine  has  10  transitions 
between  11  states  plus  one  initialization  step.  This  is  actually  an  overestimate 
of  the  number  of  control  steps  required.  As  long  as  the  implementation  produces 
the  same  results  and  heis  equivalent  observability  properties,  the  implementation 
would  be  free  to  optimize  the  average  case  by  exiting  this  sequence  of  steps 
early.  For  every  step  of  preference  semantics.  Soar  would  also  step  the  two  state 
machines  that  drive  it-  the  working  memory  phase  and  the  top  level. 

We  constructed  a  prototype  C  implementation  of  this  control  flow.  It  con¬ 
tains  all  of  the  control  flow  that  the  top  level  state  machine  and  the  working 
memory  phase  state  machine  would  require  to  step  preference  semantics  in  a 
cycle  of  11  transitions.  On  a  Decstation  5000*  ,  the  prototype  ran  11  million 
transitions  in  37  seconds.  This  is  very  likely  an  overestimate  of  an  actual  imple¬ 
mentation's  cost  because  the  heavy  calling  of  pointers  to  functions  of  this  code 
pessimizes  the  use  of  the  processor’s  instruction  cache.  When  the  control  flow  is 
augmented  with  calculation,  the  instruction  pipeline  should  be  able  to  execute 
some  of  the  calculation  instructions  in  parallel  with  the  control  flow. 

The  largest  Soar  5.2  system  that  has  been  constructed  to  date  runs  approx¬ 
imately  235,000  RHS  actions  in  7,000  seconds  on  the  same  machine.  Assuming 

‘Decstation  5000  is  a  trade  mark  of  the  Digital  Equipment  Corporation. 
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a  roughly  equal  rate  of  calls  to  preference  semantics,  Soar  5.2  requires  approxi¬ 
mately  33.6  calls  to  preference  semantics  a  second,  or  403.2  total  control  steps 
per  second.  Suppose  also  that  we  are  underestimating  the  number  of  total  con¬ 
trol  steps  by  a  factor  of  two.  This  means  that  for  every  time  the  system  takes 
one  step  inside  preference  semantics,  it  takes  two  steps  in  running  the  other 
modules  of  the  system.  Then  it  would  requires  806.4  totcil  control  steps  per  sec¬ 
ond  of  computation.  Suppose  very  ootimistically  that  Soar6  is  10  times  faster 
than  Soar  5.2.  Soar6  would  then  require  8064  total  state  machine  control  steps 
per  second.  At  37  seconds  per  11  million  steps  in  Soar6,  the  system  would  spend 
about  2.7%  of  its  time  running  the  state  machines. 

This  implementation  discipline  directly  maps  the  state  machines  into  the 
implementation  for  two  reasons:  they  allow  the  system  to  breakpoint  execution 
at  a  fine  grain,  and  they  simplify  the  mapping  from  the  specification  to  the 
code.  The  ability  to  potentially  breakpoint  at  any  state  in  the  system  allows 
users  to  precisely  select  debugging  breakpoints,  stop  the  system,  examine  its 
current  state  and  continue.  The  breakpointing  will  also  allow  the  user  to  step 
the  system  in  small  increments  providing  a  very  detailed  observation  of  the 
system  that  would  facilitate  learning  and  debugging.  The  small  cost  of  at  worst 
a  few  percent  of  total  runtime  seems  a  small  cost  to  pay  for  the  benefits  of 
breakpointing. 
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Appendix  C 

Finer  Grained  Hooks 


The  granularity  of  the  sequential  operations  in  the  specification  of  Soar  is  too 
coarse  to  allow  some  types  of  observation  of  the  system,  using  the  state  machine 
implementation  discipline.  For  example,  if  a  researcher  wanted  to  replace  the 
implementation  of  working  memory  with  a  new  data  structure,  she  would  have 
to  replace  the  implementation  of  every  operation  that  changed  the  contents  of 
working  memory.  This  requites  re-implementing  at  least  13  operations. 

We  would  like  the  specification  to  be  structured  to  localize  access  to  data 
structures  to  a  few  operations:  like  a  program  constructed  using  the  data  object 
module  paradigm.  If  we  were  to  construct  sequential  operations  such  as  Ad- 
dWME,  which  added  an  argument  working  memory  element  to  working  memory, 
we  could  still  not  easily  apply  them  because  Z’s  sequential  system  model  is  too 
weak  to  concisely  describe  the  common  operation  of  iterating  AddWME  across 
a  set  of  elements. 

Instead  of  not  specifying  the  fine  grained  operations,  and  hence  not  allowing 
their  hooking,  we  work  around  this  problem  by  requiring  the  implementation  to 
use  a  special  collection  of  fine  grained  accessors.  All  of  the  modifications  to  TM, 
WM,  PM.  SPM,  and  IM  or  GM  wi'j  call  the  operations  specified  in  this  chapter. 
Where  these  sets  ate  modified  by  set  unions  or  differences,  an  implementation 
IS  required  to  repeatedly  apply  the  individual  addition  and  deletion  operations. 

C.l  TM  Hooks 

Temporary  memory  is  hooked  at  *he  working  memory  level,  the  preference  mem¬ 
ory  level  and  the  temporary  memory  level. 
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C.1.1  WME  Operations 

AddWME  adds  its  argument  element  to  working  memory.  The  element  can 
eilready  be  in  working  memory,  in  which  case  it  is  not  re-added. 

AddWME _ 

ARM 
w?  :  WME 

WM'  =  WM  u  {w?} 

Reino'"eWME  removes  its  argument  element  from  working  memory.  The 
element  must  already  exist  in  memory,  or  an  implementation  specific  error  con¬ 
dition  is  signalled. 

I _ Remove  WME _ 

j  ARM 
j  w?  :  WME 


The  RemovePieference  opera' ion  removes  its  preference  from  preference 
memory.  The  preference  must  be  in  memory  or  an  implementation  specific 
error  condition  is  sign2dled. 

_ RemovePreference _ 

ARM 

p’  ;  Preference 
p’  €  PM 

PM'  =  PM  \  {p’’} 


202 


C.1.3  TME  Operations 

AddTME  adds  its  element  to  temporary  memory.  If  the  element  is  already  in 
memory,  temporary  memory  is  not  changed. 

AddTME _ 

ARM 

1  f?  :  TME 

!  TM’  =  TM  u  {t?} 


RemoveTME  removes  its  element  from  temporary  memory.  The  element 
must  be  in  temporary  memory  or  an  implementation  specific  error  condition  is 
signalled. 

_ Remove  TME _ 

ARM 
a  :  TME 

t?  €  TM 

TM'  =  TM  \  {t?} 


The  implementations  oi AddWME,  RemoveWME,  AddPreference,  RemovePref- 
erence,  AddTME  and  RemoveTME  respect  the  invariant  that  temporary  mem¬ 
ory  is  constructed  from  working  and  preference  memory.  For  example,  when¬ 
ever  an  operation  calls  AddWME  the  equivalent  AddTME  must  also  be  called. 
Whenever  an  operation  calls  RemoveTME  the  equivalent  RemoveWME  or  Pe¬ 
rn  ovePreference  must  also  be  called. 


C.2  SPM  Hooks 

The  Soar  production  memory,  SP,  has  productions  added  and  removed  by  name. 
The  AddSP  operation  will  only  add  in  a  production  if  there  is  not  already  one 
in  memory  of  that  name. 

_  A  ddSP _ 

ARM 
\  P'’-SP 

[  -  (Bp  :  SPM  •  p.name  =  pi  .name) 

I  SPM'  =  SPM  U  {p’} 


The  RemoveSP  operation  will  remove  a  production  given  its  name. 


203 


_ Remove  SP _ 

I  ARM 

pname  ;  Symbol 

3p  :  SPM  I  p.name  =  pname  • 
SPM'  =  SPM  \  {p} 


C.3  GM  and  IM  Hooks 

The  goal  and  impasse  memory  changes  can  be  hooked  only  for  context  impEisses, 
for  non-context  impasses  or  for  any  impasse  using  the  six  operations  specified 
in  this  section. 

C.3.1  Context  Impasses 

There  is  no  need  for  an  operation  that  hooks  the  addition  of  context  impasses, 
because  the  specification  contains  only  two  operations  that  install  them;  De- 
cideCreateFirstGoaJ  and  ImpasserCreatelmpasse. 

Although  there  is  only  one  specified  operation  that  removes  an  impasse. 
ImpasserRemovelmpase,  a  user  interface  to  Soar  requires  an  operation  to  pop 
goals  from  the  goal  stack.  RemoveContextImp&sse  is  specified  for  this  purpose. 
It  removes  a  context  impasse  from  goal  memory,  all  of  its  descendent  goals  and 
all  of  their  ImpasseWMEs.  The  implementation  should  behave  as  if  a  sequence 
of  RemoveContextlmpasse  operations  occur,  one  for  each  of  the  goals  that  would 
be  removed  to  match  this  specification,  from  newest  to  oldest. 

_ RemoveConteztImpasse _ 

A  Decide 

I  i-or_g?  :  Identifier 
t-or^g?  €  GM 

\ 

GM'  =  {GM  \  {»_or_5?})  \  GoalDescendants{i-or^g? ,  GM ,  WM) 

WM'  =  (  WM  \  Impasses  WMEs{i_or_g?,  GM,  WM)) 

\(U{s  ■  GoalDescendants(i^or^g? ,  GM ,  WM)  • 

\  Impasses  WMEs{g,  GM,  WM)}) 


C.3. 2  Non-Context  Impasses 

Non-context  impasses  are  only  generated  in  ImpasserCreatelmpasse,  and  only 
explicitly  removed  by  ImpasserRemovelmpasse.  However,  some  time  after  an 
impasse  becomes  disconnected  from  the  context  stack,  it  wUl  be  removed  from 
impasse  memory  and  it  will  have  its  working  memory  elements  removed  from 
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memory.  For  convenient  hooking  of  this  removal,  RemoveNonContextlmpasse 
is  defined  to  remove  the  impeisse  from  impasse  memory  and  remove  its  working 
memory  elements. 


_ RemoveNonContextlmpasse _ 

ADecide 

i^or^g?  :  Identifier 

i^or^g?  G  IM 

IM'  =  IM  \  {i_or_5?} 

I  WM'  =  WM  \  Impasses  WMEs(i-or _g?,  IM,  WM) 
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Appendix  D 

The  Reorderer 


The  reorderer  is  a  heuristic  greedy  search  algorithm.  It  searches  the  space  of 
possible  orderings  of  a  production’s  condition  elements  for  one  that  will  produce 
a  low  average  match  cost.  The  reorderer  does  not  improve  the  match  cost  of 
cheap  chunks  very  much,  but  it  is  important  to  reduce  the  efficiency  loss  of 
expensive  chunks. 

This  specification  is  the  result  of  an  effort  to  carefully  understand  and 
document  the  branching  factor  heuristic  of  the  greedy  search.  The  previous 
implementation fSca86l  lumped  the  conditions  into  five  equivalence  classes  with¬ 
out  carefully  understanding  the  nature  of  the  heuristic  or  the  fine  grained  test 
structure  of  the  conditions.  Consequently,  the  calculation  of  the  heuristic  was 
mixed  into  the  control  structure  of  the  search.  It  could  not  be  tailored  to  fully 
take  advantage  of  architecture  and  user  supplied  information.  Worse  still  it 
threw  up  its  hands  on  complicated  conjunctive  or  simple  disjunctive  tests  and 
assigned  them  to  an  expensive  equivalence  class. 

The  reorderer  has  three  parts:  a  classifier,  a  branching  factor  heuristic  and 
the  greedy  search  itself.  The  classifier  groups  working  memory  element  tests 
into  classes  based  upon  the  constants  and  variables  tested  in  their  components 
and  the  set  of  bound  variables  and  the  set  of  variables  constrained  to  bind  to 
impasse  identifiers.  The  classification  is  used  to  estimate  the  average  match  cost 
of  the  condition,  called  the  branching  factor  [TamQll.  The  reorderer  performs  a 
greedy  search  for  an  ordering  of  conditions  that  minimizes  the  branching  factor 
of  the  entire  ordering;  with  ties  broken  by  two  steps  of  look-ahead. 


D.l  Classifying  WMETests 

Working  memory  element  tests  are  classified  bottom  up:  the  constants  of  the 
tests  are  classified,  then  the  test  is  classified,  and  finally  the  working  memory 
element  test  is  classified. 
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The  constants  and  tests  of  the  conditions  are  classified  into  seven  classes: 

•  C —  a  test  that  tests  for  equality  with  a  constant 

•  B —  a  test  that  tests  for  equality  with  a  bound  variable 

•  U —  a  test  that  tests  for  equality  with  an  unbound  variable  or  one  that 
tests  only  for  inequality  with  a  constant  or  bound  variable 

•  GIU —  a  test  that  tests  for  equality  with  an  unbound  goal  or  impeisse 
variable 

•  GIB —  a  test  that  tests  for  equality  with  a  bound  goal  or  impasse  variable 

•  YES —  a  test  for  an  acceptable  preference  and 

•  NO —  a  test  for  not  being  an  acceptable  preference. 

The  set  TestClass  is  constructed  from  £  to  hold  the  set  of  the  possible  classes. 

C.  B,  U.  GIU,  GIB,  YES,  NO  :  £ 

TestClass  :  ?  £ 

TestClass  =  {C,  B,  U,  GIU,  GIB.  YES,  NO} 

ClassifySigma  takes  a  constant  or  variable  from  a  test,  the  set  of  bound 
variables  and  the  set  of  variables  bound  to  impasses  and  maps  them  into  one  of 
the  seven  classifications. 

ClassifySxgma  :  £  x  P  Vanable  x  P  Variable  —*  TestClass 

V  VC  :  £:  bound,  impasses  :  P  Variable  • 

((vc  €  Constant  ^  Classify Sigma{vc,  bound,  impasses)  =  C)  A 
(uc  €  Variable  => 

(uc  £  impasses  => 

(uc  €  bound  => 

ClassifySigma{vc,  bound,  impasses)  —  GIB)  A 
!  (vc  $  bound  ^ 

!  ClassifySigma{vc,  bound,  impasses)  =  GIU))  ,a 

;  (vc  €  impasses  => 

(uc  €  bound 

ClassifySigma(  vc,  bound,  impasses)  =  B)  A 
(vc  ^  bound  ^ 

ClassifySigma{vc,  bound,  impasses)  =  U)))) 

The  Classify  Test  function  takes  a  test,  the  set  of  bound  variables  and  the  set 
of  variables  bound  to  impasses  and  classifies  the  test.  Blank  tests  are  classified 
as  if  they  were  unbound  variables  because,  like  an  unbound  variable,  they  can 
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match  anything.  Yes  tests  and  No  tests  are  classified  into  YES  and  NO  classes. 
Equality  tests  are  classified  by  the  variable  or  constant  that  they  match.  Same- 
type  tests  and  not  tests  can  match  against  an  arbitrary  number  of  values,  so  they 
are  also  classified  as  unbound  variables.  Disjunctions  can  only  match  against 
one  of  a  few  constants,  so  they  are  classified  as  constants. 

Conjunctions  are  more  complicated  to  classify.  If  the  conjunction  contains  a 
disjunction  it  can  only  match  the  constants  in  the  disjunction,  so  it  is  classified 
as  a  constant.  If  it  contains  an  equality  it  is  assigned  the  classification  of  the 
equality.  If  it  contains  a  not  test  or  a  same-type  test,  it  is  treated  as  an  unbound 
variable.  These  rules  are  not  mutually  exclusive;  they  are  intended  to  be  apphed 
sequentially  to  produce  the  most  match  restrictive  classification. 

I  ClaaaifyTeat  :  Test  x  P  Variable  x  P  Variable  — *  TestClass 

j  V  <  :  Test',  bound,  impasses  :  P  Variable  • 

!  {{t  =  BlankTest  =>  Classify Test(t.  bound,  impasses)  =  U)  A 

(t  =  YesTest  =>  Classify Test(t,  bound,  impasses)  =  YES)  A 
[t  =  NoTest  =>  ClassifyTest{t.  bound,  impasses)  =  NO)  A" 

[t  £  ran  EqualityTest  => 

ClassifyTest{t, bound, impasses)  — 

ClassifySigma{EqualityTest'' (t),  bound,  impasses))  a 
I  (t  6  ran  Not  Test  ^  Classify  Test{t,  bound,  impasses)  —  U)  a 

{t  £  ran  SameTypeTest  =>  Classify Test{t ,  bound,  impasses]  =  U)  a 
{t  £  ran  DisjunctiveTest  ClassifyTest{t,  bound,  impasses)  =  C)  A 
{t  £  ran  ConjunctiveTest  => 

I  ((3  c  :  ConjunctiveTest'’ (t)  •  c  £  run  DisjunctiveTest)  => 

Classify Test{t.  bound ,  impasses)  =  C)  a 

((3c;  ConjunctiveTest" (t)  •  c  £  ran  EqualityTest)  => 

\  (3  c:  ConjunctiveTest" (t)  n  ran  EqualityTest  • 

I  ClassifyTest{t,bound,impasses)  — 

[  Classify Sigma{EqualityTest" (c),  bound,  impasses)))  A 

I  ((3  c  :  ConjunctiveTest" {t)  •  c  £  run  NoiTest) 
j  =s-  Classify Test(t,  bound,  impasses)  =  U)  A 

j  ((3  c  :  ConjunctiveTest" [t)  •  c  £  ran  SameTypeTest)  => 

ClassifyTest{t,  bound,  impasses)  =  U))) 
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The  WMETestClass  schema  holds  classifications  for  an  entire  WMEtest.  The 
WME  test  class  uses  £  as  the  value  of  the  attribute  and  value  components  so 
that  the  classes  can  be  used  to  map  attribute  and  value  specific  classifications  to 
branching  factors.  The  system  and  the  user  can  then  enter  default  information 
about  the  branching  factors  of  conditions  in  a  uniform  manner. 

_  WMETestClass - - 

id  :  TesiClass 
!  attribute  :  £ 
value  :  £ 

i  context  ^acceptable -preference  ;  {YES,  NO} 

1  _ _ 

The  description  of  the  derivation  of  the  branching  factor  table  requires  the 
instantiation  of  90  WME  test  classes.  For  brevity,  the  WC  constructor  is  defined 
to  instantiate  the  WME  test  classes. 

WC  :  TestClass  x  TestClass  x  TestClass  x  TestClass  — >  WMETestClass 

I 

V  id  :  TestClass',  attribute  :  TestClass-,  value  :  TestClass-, 
i  context -acceptable -preference  :  {YES,  NO}  • 

W C {id.  attribute,  value,  context -acceptable -prefe-rence)  = 

;  (/lid  :  {id};  attribute  ;  {attribute},  value  :  {voiue}; 

I  context -acceptable -preference  :  {context -acceptable -preference]  • 

e  WMETestClass) 

ClassifyWMETest  classifies  a  WME  test  given  the  set  of  bound  variables 
and  the  set  of  variables  bound  to  impasses.  For  the  attribute  and  values  the 
goal  and  impasse  variables  are  not  passed  to  Classify  Test  so  that  classify  test 
will  classify  goal  variables  in  these  slots  as  normal  variables. 

ClassifyWMETest  ;  WMETest  x  P  Variable  x  P  Variable  — *  WMETestClass 

v  wt  :  WMETest:  bound ,  impasses  :  P  Variable  • 

Classify  WMETest{wt,  bound,  impasses)  = 

WC (ClassifyTest{wt.id,  bound,  impasses), 

I  Classify Test{wt. attribute,  bound,  0), 

I  ClassifyTest(-wt. value,  bound,  0), 

ClassifyTest{wt.context-acceptable-preference,!Z,  0)) 


D.2  Deriving  the  Branching  Factor  Heuristic 

The  branching  factor  is  a  measure  of  the  average  cost  to  match  a  single  condition, 
given  the  set  of  bound  variables  and  the  set  of  variables  bound  to  impasses.  The 
principled  derivation  of  this  heuristic  is  complicated.  There  are  90  (5  *  3  *  3  * 
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2)  equivalence  classes  of  WME  test;  as  the  identifier  slot  of  a  WME  test  can  be 
classified  five  ways,  the  attribute  and  value  each  three  ways  and  the  preference 
two  ways. 

The  analysis  of  these  ninety  cases  into  branching  factors  is  derived  from  five 
measures  of  the  average  branching  of  the  graph  of  working  memory. 

1.  G  —  the  average  number  of  goal  and  impasses  in  the  system. 

2.0  —  the  average  number  of  objects  in  the  system. 

Z.  A  —  the  average  number  of  attributes  per  object  in  the  system. 

4.  V  —  the  average  number  of  values  for  any  attribute  in  the  system. 

5.  AP  —  the  average  number  of  context  acceptable  preferences  per  values. 

G,0,A,V,AP:2 

I  G>OaO>OaO>OaV'>Oa  AP  >  0 

The  branching  factor  for  each  WME  test  is  calculated  by  multiplying  to¬ 
gether  the  average  measure  for  each  slot  that  the  condition  leaves  unconstrained. 

The  following  table  derives  the  average  case  match  estimate  for  all  90  cases. 
This  table  is  provided  only  to  allow  discussion  of  the  correctness  of  this  measure. 
The  implementation  will  use  a  closed  form  of  this  function  that  is  specified  next. 

1.  WC(C,C,C,YES)  =  1 

2.  WC(C,C,C,NO)  =  1 

3.  WC(C,C,B,YES)  =  1 
4  WC(C,C,B,NO)  =  1 

5.  WC(C,C,U,YES)  =  V  *  AP 

6.  WC(C,C,U,NO)  =  V 

7.  WC(C,B,C,YES)  =  1 

8.  WC(C,B,C,NO)  =  1 

9.  WC(C,B,B,YES)  =  1 

10.  WC(C,B,B,NO)  =  1 

11.  WC(C,B,U,YES)  =  V  •  AP 

12.  WC(C.B.U.NO)  =  V 
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13.  WC(C.U,C,YES)  =  A 

14.  WC(C,U.C,NO)  =  A 

15.  WC(C,U,B,YES)  =  A 

16.  WC(C,U,B,NO)  =  A 

17.  WC(C,U,U.YES)  =  A  •  V  •  AP 

18.  WC(C.U,U,NO)  =  A  •  V 

19.  WC(B,C,C,YES)  =  1 

20.  WC(B,C.C,NO)  =  1 

21.  WC(B,C,B,YES)  =  1 

22.  WC(B,C,B,NO)  =  1 

23.  WC(B,C,U.YES)  =  V  *  AP 

24.  WC(B,C,U.NO)  =  V 

25.  WC(B,B,C,YES)  =  1 

26.  WC(B,B.C,NO)  =  1 
27  WC(B,B,B,YES)  =  1 

28.  WC(B,B,B,NO)  =  1 

29.  WC(B,B.U,YES)  =  V  *  AP 

30.  WC(B,B,U,NO)  =  V 
31  WC(B,U.C,YES)  =  A 

32.  WC(B,U,C,NO)  =  A 

33.  WC(B,U,B,YES)  =  A 

34.  WC(B,U,B.NO)  =  A 

35.  WC(B,U,U,YES)  =  A  *  V  *  AP 

36.  WC(B,U,U.NO)  =  A  *  V 

37.  WC(U,C,C.YES)  =  O 

38.  WC(U,C,C.NO)  =  O 

39.  WC(U,C.B,YES)  =  O 
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40.  WC(U,C,B,NO)  =  O 

41.  WC(U,C,U,YES)  =  O  *  V  •  AP 

42.  WC(U,C,U,NO)  =  O  *  V 

43.  WC(U,B,C,YES)  =  O 

44.  WC(U,B,C,NO)  =  O 

45.  WC(U,B,B,YES)  =  O 

46.  WC(U,B,B,NO)  =  O 

47.  WC(U,B,U,YES)  =  O  *  V  *  AP 

48.  WC(U,B,U,NO)  =  O  *  V 

49.  WC(U,U,C,YES)  =  O  *  A 

50.  WC(U,U,C,NO)  =  O  •  A 

51.  WC(U,U,B,YES)  =  O  *  A 

52.  WC(U,U,B,NO)  =  O  *  A 

53.  WC(U,U,U,YES)  =  O  *  A  *  V  *  AP 

54.  WC(U,U,U,NO)  =  O  •  A  •  V 

55.  WC(GIU,C,C,YES)  =  G 

56.  WC(GIU,C.C,NO)  =  G 

57.  WC(GIU,C,B.YES)  =  G 

58.  WC(GIU,C,B,NO)  =  G 

59.  WC(GIU,C,U,YES)  =  G  *  V  *  AP 

60.  WC(GIU,C,U,NO)  =  G  *  V 

61.  WC(GIU,B,C,YES)  =  G 

62.  WC(GIU,B,C,NO)  =  G 

63.  WC(GIU,B,B.YES)  =  G 

64.  WC(GIU.B,B,NO)  =  G 

65.  WC(GIU,B.U,YES)  =  G  *  V  *  AP 

66.  WC(GIU,B.U,NO)  =  G 
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67.  WC(GIU,U  C,YES)  =  G  *  A 

68.  WC(GIU,U,C,NO)  =  G  *  A 

69.  WC(GIU,U,B,YES)  =  G  *  A 

70.  WC(GIU,U,B,NO)  =  G  *  A 

71.  WC(GIU,U,U,YES)  =  G  *  A  '  V  » 

72.  WC(GIU,U,U,NO)  G  ’  A  «  V 

73.  WC(GIB,C,C,YES)  =  1 

74.  WC(GIB,C,C.NO)  =  1 

75.  WC(GIB.C,B,YES)  =  1 
76  WC(GIB.C,B.NO)  =  1 

77.  WC(GIB.C,U,YES)  =  V  *  AP 

78.  WC(GIB,C,U,NO)  =  V 

79.  WC(GIB,B,C,YES)  =  1 

80.  WC(GIB.B,C,NO)  =  1 

81.  WC(GIB.B,B,YES)  =  1 

82.  \VC(GIB,B,B,NO)  =  1 

83.  WC(GIB,B,U,YES)  =  V  *  AP 

84.  WC(GIB,B,U,NO)  =  V 

85.  WC(GIB,U,C,YES)  =  A 

86.  WC(GIB,U,C,NO)  =  A 

87.  WC(GIB,U,B,YES)  =  A 

88.  WC(GIB,U,B,NO)  =  A 

89.  WC(GIB,U,U,YES)  =  A  *  V  *  AP 

90.  WC(GIB,U,U,NO)  =  A  ‘  V 


AP 
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This  formulation  is  overly-genetal  because  each  production’s  conditions  must 
all  be  connected  to  an  impasse.  So  all  of  the  cases  of  the  form  IVC(U, . , wUl 
never  be  used.  The  current  system  assumes  that  any  conditions  of  the  form: 
1TC(B,  C,  U,  NO)  are  uni-attributes,  e.g.,  have  a  branching  factor  of  1,  unless 

told  otherwise  with  a  multi-attributes  declaration. 

The  branching  factor  table  of  90  cases  is  too  large  for  easy  use.  A  closed 

form  for  this  table,  named  ABF,  can  be  derived  from  the  observation  that  the 
average  branching  factor  of  a  WME  test  class  is  the  average  branching  factor  of 
its  identifier  (ABFI)  multiplied  by  the  average  branching  fa'^tor  of  its  attribute 
(ABFA)  and  the  average  branching  factor  of  its  value  acceptable  preference 
combination  (ABFVAP). 

ABF,  ABFI,  ABFA,  ABFVAP  :  WMETestClass  ^  2 

V  wtc  •  WMETestClass  • 

i  ABF(wtc)  =  ABFI{wic)  »  ABFA(wtc)  «  ABFVAP(wic) 

V  wtc  :  WMETestClass  • 

'  ((wtc. id  c  {C,B.GIB}  =>  ABFI(wtc)  =  1)  A 
(wtc. id  =  GIU  =>  ABFI(wtc)  =  G)  A 
;  (wtc. id  =  U  =>  ABFI(wtc)  —  O)) 

\  V  wtc  :  WMETestClass  • 

((wtc. attribute  =  U  =>  ABFA(wtc)  =  A)  A 
(wtc . attribute  =  U  =>  .ABFA(wtc)  =  i)) 

V  wtc  :  WMETestClass  • 

((wtc. value  U  =>  ABFVAP(wtc)  —  1)  A 
:  (wtc.va'.,e  =  U  A  wtc.  context  ^acceptable  ^preference  =  YES 

ABFVAP(wtc)  =  /  »  AP)  A 

j  (wtc.  value  =  U  A  wtc.  context  ^acceptable  ^preference  —  NO 
'  ^  ABFVAP(wtc)  =  V)) 

Soar  users  may  care  to  provide  information  about  branching  factors  of  spe¬ 
cific  condition  classes,  and  the  system  should  have  default  knowledge  about 
conditions  that  match  context  stack  attributes.  The  user  only  cares  to  provide 
an  average  branching  factor  for  the  multi-attribute  cases: 

PrG(B,C,U,NO)  and  W''C(B,  C,  U,  YES). 

Using  this  classification  scheme,  the  system  can  take  advantage  of  some 
knowledge  of  the  average  case  structure  of  the  context  stack: 

•  IUC(GIU,' OBJECT', 'NIL '.NO)  =  1  and 

IUC(GIB, '  OBJECT  ', '  NIL  ',  NO)  =  1  —  there  is  only  one  goal  with  no 
supergoal. 

•  IUC(GIU, 'OBJECT ',U.  NO)  =  1  and 

W''C(GIB.  '  OBJECT ',  U,  NO)  =  1  —  there  is  only  one  supergoal  for  each 
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goal. 


•  H'-C{GIL', '  PROBLEM-SPACE  U,  NO)  =  (7, 

M'’C(GIU,  '  STATE  U,  NO)  =  G  and 

B'’C(GIU,  ‘  OPERATOR U,  NO)  =  G  —  on  average  every  goal  has  a 
problem  space,  state  and  operator. 

•  M''C(GIB,  •  PROBLExM-SPACE  U,  NO)  =  1, 

WCIGIB.' STATE '.U.NOl  -  1  and 

H'’C(GIB,  “  OPERATOR  U,  NO)  =  G  —  each  specific  goal  has  on  aver¬ 
age  one  problem-space,  state  or  operator. 

•  M''C(GIB, '  ITEM  U,NO)  >1  —  ou  average  the  items  augmentation  of 
a  goal  holds  more  than  one  thing 

The  user  branching  factor  function.  FBE,  is  provided  to  capture  the  user’s 
knowledge  of  condition  branching  factors.  A  user  interface,  like  Soarh’s  multi¬ 
attributes  ([LCAS90I  178),  should  be  provided  to  allow  the  user  to  extend  UBF 

UBF  :  WMETestClass  —  2 

The  system  stores  its  knowledge  of  branching  factors  in  the  default  branching 
factor  function,  DBF.  DBF  assumes  that  the  W'G(B,  C,  U,  NO)  case  is  a  uni- 
attribute. 

DBF  ■  WMETestClass  —  2 

DBF  =  {(  H'C(GIU,‘ OBJECT '.'NIL',  NO).  1). 

(  M-C(GIB,  •  OBJECT  *  NIL  *.  NO).  1), 

(  U  C(GIU,  *  OBJECT',  U,  NO).  1), 

(  H'’C(GIB,  ■  OBJECT U,  NO).  1), 

(  WC(GIU, '  PROBLEM-SPACE  U.  NO),  G), 

(  H’C(GIU,  •  STATE  '.  U,  NO).  G). 

( VTC(GIU,  •  OPERATOR '.  U.  NO),  G), 

( l^’GfGIB, '  PROBLEM-SPACE  '.  U  NO).  1), 

( 1TC(GIB, '  STATE U,  NO),  1), 

(1TC(GIB, 'OPERATOR '.U,  NO).  1), 
(lTC(GIB.'ITEM'.U.NO).2), 

(H'C(B,C,U.NO),l)} 
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BF  takes  two  WME  tests  for  arguments.  The  first  is  the  WME  test  generated 
by  the  classifier.  The  second  is  the  classifier  with  one  of  the  possible  constants 
of  the  attribute  and/or  value  tests  installed  instead.  BF  checks  if  the  system 
or  the  user  has  any  constant  specific  branching  information.  If  so  it  is  used, 
otherwise  the  system  uses  the  average  branching  factor. 

I  BF  :  WMETeatClass  x  WMETestClass  — >  Z 
[ _ 

I  ^  prototype ,  instantiated  :  WMETestClass  • 

\  (instantiated  €  dom{DBF  ©  UBF)  => 

j  BF  (prototype,  instantiated)  =  (DBF  @  UBF)(mstantiated))  A 

I  (instantiated  ^  dom(DBF  ®  UBF)  => 
j  BF  (prototype,  instantiated)  =  ABF  (prototype)) 

The  reorderer  must  check  the  constant  specific  branching  factor  information 
for  any  positive  constants  that  appear  in  attribute  or  value  tests. 

I  Contains  Positive  Constants^  :  !?  Test 
i  V  t  ;  Test  • 

I  Contains  Positive  Constants  (t)  «• 

( t  €  ran  Disjunctive  Test  v 

t  €  inn  EqualityTest  A  EqualityTest'' (t)  E  Constant  V 
I  t  E  ran  Conjunctive  Test  A 

;  (3  c:  ConjunctiveTest" (t)  •  c  E  run  DisjunctiveTest  v 

!  (c  E  run  EqualityTest  A  EqualityTest"  (c)  E  Constant))) 
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The  Soar5  reorderer  would  not  correctly  classify  many  conditions  that  in¬ 
volved  disjunctions  or  conjunctions  in  the  attributes.  SBF  carefully  picks  the 
maximum  branching  factor  for  the  set  of  constants  of  the  attribute  or  value  tests 
of  the  WME  test. 

i  SBF  :  WMETestClass  x  WMETest  Z 

j  V  uitc  :  WMETestClass:  tot  :  WMETest  • 

( ( Contains  Positive  Constants  ( wt .  attribute )  A 
ContainsPosiliveConstants{wt.value)  ::s- 
SBF{wtc,  wi)  = 

max{a  :  TestsPo$itiveComponi^nts{wt. attribute)  T'  Constant: 

V  :  TestsPositiveComponentslwt. value)  ^  Constant  • 

BF(wtc,  WC(wtc. id,  a,  v^wtc. context -acceptable -preference))})  a 
( ContainsPosttiveConsiants(wt.attribute)  A 
^  ContainsPosiiiveConstants(wt.value)  => 

SBF(ujic,  wt)  = 

max  {a  :  TestsPositiveComponenis{wt.  attribute)  <’'■  Constant  • 

BF{wtc,  WC{wtc.id.  a,  wtc. value,  wtc.context-acceptable-preference))}) 
(—  ContainsPositiveConstants(wt.attribute)  A 
-  ContainsPositiveConstants(wt.value)  => 

SBF{wtc,  wt)  =  ABF(wtc)  =  BF(wtc,  wtc))) 

SBF  will  allow  the  reorderer  to  correctly  order  conditions,  like  this  one  from 
the  default  productions,  containing  the  common  idiom  of  binding  to  a  disjunc¬ 
tion. 

(<s>  *{  <<  required-success  success  partial-success 
...  >>  <svalue>  }  <eb>  ) 

In  this  case,  the  reorderer  can  tell  that  this  disjunction  is  a  uni-attribute, 
not  a  multi-attribute. 
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The  concept  of  a  WME  test’s  branching  factor  can  be  elevated  to  conditions. 

The  branching  factor  of  a  positive  condition  is  the  branching  factor  of  its  WME 
test.  Negative  conditions  can  not  be  added  until  all  of  the  variables  that  they 
share  with  the  positive  conditions  have  been  bound.  When  a  negative  condition 
is  added,  its  branching  factor  is  one  because  it  only  filters  the  set  of  matches.  For 
convenience,  if  the  negative  condition  does  not  have  all  of  its  variables  bound  it 
is  assigned  an  arbitrarily  huge  branching  factor. 

ConditionsBranchmgractoT  : 

Condition  x  P  Variable  x  P  Variable  x  P  Variable  — *  Z 

Vc  :  Condition;  bound,  positive,  impasses  :  P  Variable  • 

'  ((c  €  ran  PositiveCondition 

I  {3  wt  :  WMETest  |  wt  =  PositiveCondition'' [c)  • 

[  ConditionsBranchingFactor{c,  bound,  positive,  impasses)  — 

SBF(ClassifyWMETest{wt,  bound,  impasses),  wt)))  A 
(c  r  ran  Negative  Condition  U  ran  Negative  Conjunctive  Condition  => 
[{{ConditionsPositiveComponents(c)  Variable)  ^  positive  C  bound)  => 
ConditionsBranchingFactor[c,  bound,  positive,  impasses)  =  1)  A 
(-i  {( Conditions PositiveComponents{c)  C  Variable)  positive  C  bound)  => 
ConditionsBranchingFactor(c,  bound,  positive,  impasses)  =  Infinity))) 


D.3  The  Reorderer’s  State 

The  reorderer’s  state  machine  uses  three  states: 

1.  ReordererlnitiaJState  —  the  machine  starts  in  this  state. 

2.  ReordererAddConditionState  —  the  machine  adds  conditions  in  this  state. 

3.  ReordeierFinishedState  —  the  machine  finishes  in  this  state. 


ReordererState  Reorderer Initials tate 

\  ReordererAddConditionState 
\  Reorderer  FinishedS  tate 
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Figure  D.l:  Reorderer  State  Machine 
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The  Reorderei  schema  holds  a  state  counter  and  seven  pieces  of  state: 

1.  ordering  —  the  sequence  of  conditions  selected  so  far 

2.  conditions  —  the  set  of  conditions  of  the  production’s  LHS  that  have  not 
been  added  to  the  ordering 

3.  impasses  —  the  set  of  variables  that  the  condition  binds  to  goal  and  im¬ 
passe  identifiers 

4.  bound  —  the  set  of  variables  bound  in  a  condition  already  in  the  ordering 

5  positive  —  the  set  of  variables  bound  in  all  of  the  positive  conditions  and 

6.  branching— factor  —  the  estimated  average  cost  of  matching  the  entire 
ordering. 


_ Reorderer _ 

reorderer  state  :  Reorderer  State 
ordering  :  seq  Condition 
conditions  :  P  Condition 
impasses ,  bound ,  positive  :  P  Variable 
\  branching -factor  : 


When  the  reorderer  is  initialized  it  must  start  with  a  set  of  conditions  to  order 
and  an  empty  ordering.  The  branching  factor  of  an  empty  ordering  is  defined 
to  be  one.  The  set  of  bound  variables  is  empty  because  no  conditions  have  been 
added  to  the  ordering.  Only  goal  or  impasse  conditions  can  be  selected  to  start, 
so  there  must  be  some  goal  or  impasse  variables.  The  positive  variables  are  the 
variables  bound  positively  in  the  positive  conditions. 

_ InitReorderer _ 

Reoru<.rer 

I  conditions  5^  0 

I  ordering  =  {) 

i  bound  =  0 

branching -factor  =  1 

! 

;  impasses  0 
positive  = 

I  (U( ConditionsPositiveComponents^conditions  n  ran  PositiveCondition]j)) 
n  Variable 
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When  the  reorderer’s  state  is  changed  the  root  conditions  and  positive  vari¬ 
ables  remain  unchanged.  With  each  step,  the  set  of  bound  conditions  grows 
and  the  branching  factor  is  non-decreasing.  The  last  predicate  ensures  that  the 
reorderer  either  adds  a  condition  to  the  end  of  ordering  or  leaves  it  unchanged. 

^  AReorderer _ 

I  Reorderer 
Reorderer' 

impasses'  =  impasses 

! 

I  positive'  =  positive 
bound  C  bound' 

branching-factor'  >  branching -factor 
i  ordering'  =  ordering  V  tail{ordering)  =  ordering' 


D.4  The  Reorderer’s  Operations 

InitializeReorderer  moves  the  state  machine  from  the  finished  state  into  the 
initial  state  and  ensures  that  the  reorderer’s  configuration  is  a  valid  initied  con¬ 
figuration. 

. _ InitiaiizeReorderer _ 

AReorderer 

reorderer -State  —  ReordererFinishedState 
InitReorderer 

reorderer -State'  =  Reorderer  ImtialState 

The  machine’s  first  action  is  to  move  to  the  add  condition  state. 

_ StartReorderer _ 

I  AReorderer 

reorderer -State  =  ReordererInitialState 
reorderer -State'  =  Reorderer  AddConditionState 
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The  BestConditions  function  selects  the  subset  of  conditions  that  have  a 
mminium  blanching  factor. 

BestConditions  : 

I  P  Condition  x  P  Variable  x  P  Variable  x  P  Variable  — *  P  Condition 

V  C  :  P  Condition;  bound,  positive,  impasses  :  P  Variable  • 
BestConditions{  C .  bound,  positive,  impasses)  = 

{c  .  C  I 

--  (5  C2  :  C  • 

I  CondiiionsBranchingFactor{c'2,bound,posittve,impasses)  < 

•  Conditions  Branching  Factor  [c,  bound,  positive,  impasses))} 

When  there  is  a  unique  best  condition  or  the  branching  factor  of  all  of 
the  conditions  is  one,  the  reorderer  will  add  a  condition  from  the  set  of  best 
conditions.  The  reorderer  picks  any  one  of  the  best  conditions  and  adds  it  to 
the  end  of  the  ordering.  It  updates  the  estimate  of  the  cost  of  the  ordering  by 
multiplying  it  by  the  condition's  branching  factor,  The  positive  variables  of  the 
added  condition  are  added  into  the  set  of  bound  variables. 

, _ Reorderer  AddBestCondition _ 

Reorderer 

reorderer  ^state  =  Reorderer  AddConditionState  =  reorderer  ^state' 

i^{BestConditions{conditions.  bound,  positive,  impasses))  =  1  v 
(V  c  :  BestConditions(conditions .  bound,  positive,  impasses)  • 
ConditionsBranchtngFactor(c.  bound,  positive,  impasses)  —  1) 

5  c  :  BestConditions{conditions ,  bound,  positive,  impasses)  • 

(conditions'  =  conditions  .  {c}  a 
ordering'  =  ordering  ~  (C)  A 
branching  ^factor'  =  branching  ^factor* 

ConditionsBranchingFactor(c,  bound,  positive,  impasses)  A 
bound'  =  bound  L.  {ConditionsPositiveCoraponents(c)  ''  Variable)) 
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LookAhead  is  given:  a  condition,  the  set  of  all  conditions  yet  to  be  chosen, 
the  bound  variables,  the  positive  variables  and  the  goal  or  impasse  variables.  It 
calculates  the  branching  factor  for  first  adding  the  condition  and  then  adding 
the  best  of  the  remaining  conditions. 

i  LookAhead  : 

I  Condition  x  P  Condition  x  P  Variable  x  P  Variable  x  P  Variable  — >  Z 

V  Cl  :  Condition;  C  :  P  Condition;  bound,  positive,  impasses  :  P  Variable  Ci  ■£  C  • 
z  newbounds  :  P  Variable 

I  newbounds  =  bound  ^  ( Conditions  PositiveComponents(ci)  n  Variable)  • 

3  C2  :  BestCondttions{C  \  {cj}.  bound,  positive,  impasses)  • 

'  LookAhead) Cl,  C.  bound ,  positive ,  impasses)  = 

I  ConditionsBranchingFactor{ci .  bound,  positive,  impasses)* 

ConditionsBranchingFactor{ci,  newbounds ,  positive,  impasses) 

BestTiedConditions  is  used  to  break  ties  between  conditions  It  returns  the 
set  of  conditions  that  have  the  minimum  branching  factor  after  one  step  of 
lookahead. 

BestTiedConditions  : 

I  P  Condition  x  P  Variable  x  P  Variable  x  P  Variable  — *  P  Condition 

^  C  .P  Condition,  bound,  positive,  impasses  :  P  Variable  • 

BestTiedConditions{C .  bound,  positive,  impasses)  = 

{ci  :  BestConditions(  C,  bound,  positive,  impasses) 

-  (3  C2  :  BestConditions{C .  bound,  positive,  impasses)  • 

LookAhead{c2.  C  '  {ci}.  bound .  positive .  impasses)  < 

LookAhead{c\,  C  {ci},  bound ,  positive ,  imposses))} 
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Whenever  there  is  a  tie  for  the  best  condition  and  all  of  the  tied  conditions 
have  a  branching  factor  of  greater  than  one,  ReordererAddBestTiedCondition 
selects  one  of  the  best  tied  conditions  and  adds  it  to  the  ordering. 

_ ReordererAddBesiTtedConditton _ 

AReorderer 

reorderer^atate  =  ReordererAddConditionState  =  reorderer  _state' 

(:^(BeatCondittona(condittons.  bound,  poaiUve,  tmpasaea))  =  1  v 
(r  c  ,  Be$tConditions{condittona .  bound,  positive,  impasses)  • 
CondttionsBranchingFactor{c,  bound,  positive,  impasses)  —  1)) 

I  Be  ;  BestTiedConditiona{condttions,  bound,  positive,  impasses)  • 
(conditions'  =  conditions  \  {c}  A 
ordering'  =  ordering  ^  (c)  A 
branching  ^factor'  = 
branching  ^factor* 

ConditionsBranchingFactor(c.  bound,  positive,  impasses)  A 
bound'  ~  bound  ,j  (ConditionsPositiveComponents(c)  ^  Variable)) 


When  all  of  the  conditions  have  been  added  to  the  ordering,  FinishReorderet 
moves  the  reorderer  into  the  finished  state. 

_ FinishReorderer  _ 

AReorderer 

reorderer  ^state  =  ReordererAddConditionState 
conditions  =  2 

reorderer  ^state'  —  Reorderer  FinishedState 


StepReorderer  steps  the  reorderer. 

StepReorderer  =  StartReorderer  v 

Reorderer AddBestCondition  v  ReordererAddBestTiedCondition  v 
FinishReorderer 

ResetReorderer  allows  the  system  to  reset  the  reorderer  to  the  finished  state 
from  any  state. 

_ ResetReorderer _ 

A  Reorderer 

reorderer  _  state'  =  Reorderer  FinishedState 
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For  simplicity,  the  reordering  of  conjunctive  negations  has  not  been  specified. 
Whenever  a  conjunctive  negation  is  added  to  the  ordering  the  system  should 
reorder  the  conditions  of  the  negation  using  the  same  algorithm.  It  should  start 
with:  an  empty  ordering,  the  bound  variables  of  the  entire  ordering,  the  roots  of 
the  entire  ordering  and  the  positively  tested  variables  of  the  positive  conditions 
of  the  conjunctive  negation. 
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